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Preface 



Many books on formal semantics begin by explaining that there are three major 
approaches to semantics, that is 

• operational semantics, 

• denotational semantics, and 

• axiomatic semantics; 

but then they go on to study just one of these in greater detail. The purpose of 
this book is to 

• present the fundamental ideas behind all of these approaches, 

• to stress their relationship by formulating and proving the relevant theorems, 
and 

• to illustrate the applicability of formal semantics as a tool in computer 
science. 

This is an ambitious goal and to achieve it, the bulk of the development con- 
centrates on a rather small core language of while-programs for which the three 
approaches are developed to roughly the same level of sophistication. To demon- 
strate the applicability of formal semantics we show 

• how to use semantics for validating prototype implementations of program- 
ming languages, 

• how to use semantics for verifying analyses used in more advanced imple- 
mentations of programming languages, and 

• how to use semantics for verifying useful program properties including infor- 
mation about execution time. 

The development is introductory as is already reflected in the title. For this rea- 
son very many advanced concepts within operational, denotational and axiomatic 
semantics have had to be omitted. Also we have had to omit treatment of other 
approaches to semantics, for example Petri-nets and temporal logic. Some pointers 
to further reading are given in Chapter 7. 
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Overview 

As is illustrated in the dependency diagram, Chapters 1, 2, 4, 6 and 7 form the core 
of the book. Chapter 1 introduces the example language of while-programs that 
is used throughout the book. In Chapter 2 we cover two approaches to operational 
semantics, the natural semantics of G. Kahn and the structural operational se- 
mantics of G. Plotkin. Chapter 4 develops the denotational semantics of D. Scott 
and C. Strachey including simple fixed point theory. Chapter 6 introduces pro- 
gram verification based on operational and denotational semantics and goes on to 
present the axiomatic approach due to C. A. R. Hoare. Finally, Chapter 7 contains 
suggestions for further reading. 

The first three or four sections of each of the Chapters 2, 4 and 6 are devoted 
to the language of while-programs and covers specification as well as theoretical 
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aspects. In each of the chapters we extend the while-language with various other 
constructs and the emphasis is here on specification rather than theory. In Sections 
2.4 and 2.5 we consider extensions with abortion, non-determinism, parallelism, 
block constructs, dynamic and static procedures, and non-recursive and recursive 
procedures. In Section 4.5 we consider extensions of the while-language with 
static procedures that may or may not be recursive and we show how to handle 
exceptions, that is, certain kinds of jumps. Finally, in Section 6.4 we consider an 
extension with non-recursive and recursive procedures and we also show how total 
correctness properties are handled. The sections on extending the operational, 
denotational and axiomatic semantics may be studied in any order. 

The applicability of operational, denotational and axiomatic semantics is illus- 
trated in Chapters 3, 5 and 6. In Chapter 3 we show how to prove the correctness 
of a simple compiler for the while-language using the operational semantics. In 
Chapter 5 we prove an analysis for the while-language correct using the denota- 
tional semantics. Finally, in Section 6.5 we extend the axiomatic approach so as 
to obtain information about execution time of while-programs. 

Appendix A reviews the mathematical notation on which this book is based. It 
is mostly standard notation but some may find our use of <^-> and o non-standard. 
We use D <^-> E for the set of partial functions from D to E; this is because we 
find that the D — E notation is too easily overlooked. Also we use R o S for 
the composition of binary relations R and S] this is because of the different order 
of composition used for relations and functions. When dealing with axiomatic 
semantics we use formulae { P } S { Q } for partial correctness assertions but 
{P}S{^Q}ion: total correctness assertions because the explicit occurrence of 
JJ- (for termination) may prevent the student from confusing the two systems. 

Appendices B, C and D contain implementations of some of the semantic speci- 
fications using the functional language Miranda. 1 The intention is that the ability 
to experiment with semantic definitions enhances the understanding of material 
that is often regarded as being terse and heavy with formalism. It should be pos- 
sible to rework these implementations in any functional language but if an eager 
language (like Standard ML) is used, great care must be taken in the imple- 
mentation of the fixed point combinator. However, no continuity is lost if these 
appendices are ignored. 

Notes for the instructor 

The reader should preferably be acquainted with the BNF-style of specifying the 
syntax of programming languages and should be familiar with most of the mathe- 
matical concepts surveyed in Appendix A. To appreciate the prototype implemen- 
tations of the appendices some experience in functional programming is required. 



1 Miranda is a trademark of Research Software Limited, 23 St Augustines Road, Canterbury, 
Kent CT1 1XP, UK. 
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We have ourselves used this book for an undergraduate course at Aarhus University 
in which the required functional programming is introduced "on-the-fly" . 

We provide two kinds of exercises. One kind helps the student in his/her 
understanding of the definitions/results/techniques used in the text. In particular 
there are exercises that ask the student to prove auxiliary results needed for the 
main results but then the proof techniques will be minor variations of those already 
explained in the text. We have marked those exercises whose results are needed 
later by "(Essential)". The other kind of exercises are more challenging in that 
they extend the development, for example by relating it to other approaches. We 
use a star to mark the more difficult of these exercises. Exercises marked by two 
stars are rather lengthy and may require insight not otherwise presented in the 
book. It will not be necessary for students to attempt all the exercises but we 
do recommend that they read them and try to understand what the exercises are 
about. 
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Chapter 1 
Introduction 



The purpose of this book is 

• to describe some of the main ideas and methods used in semantics, 

• to illustrate these on interesting applications, and 

• to investigate the relationship between the various methods. 

Formal semantics is concerned with rigorously specifying the meaning, or be- 
haviour, of programs, pieces of hardware etc. The need for rigour arises because 

• it can reveal ambiguities and subtle complexities in apparently crystal clear 
defining documents (for example programming language manuals), and 

• it can form the basis for implementation, analysis and verification (in par- 
ticular proofs of correctness). 

We will use informal set theoretic notation (reviewed in Appendix A) to represent 
semantic concepts. This will suffice in this book but for other purposes greater 
notational precision (that is, formality) may be needed, for example when process- 
ing semantic descriptions by machine as in semantics directed compiler-compilers 
or machine assisted proof checkers. 

1.1 Semantic description methods 

It is customary to distinguish between the syntax and the semantics of a pro- 
gramming language. The syntax is concerned with the grammatical structure of 
programs. So a syntactic analysis of the program 

z: =x; x:=y; y:=z 
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will realize that it consists of three statements separated by the symbol Each 
of these statements has the form of a variable followed by the composite symbol 
':=' and an expression which is just a variable. 

The semantics is concerned with the meaning of grammatically correct pro- 
grams. So it will express that the meaning of the above program is to exchange 
the values of the variables x and y (and setting z to the final value of y). If we 
were to explain this in more detail we would look at the grammatical structure of 
the program and use explanations of the meanings of 

• sequences of statements separated by an d 

• a statement consisting of a variable followed by ':=' and an expression. 

The actual explanations can be formalized in different ways. In this book we shall 
consider three approaches. Very roughly, the ideas are as follows: 

Operational semantics: The meaning of a construct is specified by the compu- 
tation it induces when it is executed on a machine. In particular, it is of 
interest how the effect of a computation is produced. 

Denotational semantics: Meanings are modelled by mathematical objects that 
represent the effect of executing the constructs. Thus only the effect is of 
interest, not how it is obtained. 

Axiomatic semantics: Specific properties of the effect of executing the con- 
structs are expressed as assertions. Thus there may be aspects of the execu- 
tions that are ignored. 

To get a feeling for their different nature let us see how they express the meaning 
of the example program above. 

Operational semantics (Chapter 2) 

An operational explanation of the meaning of a construct will tell how to execute 
it: 

• To execute a sequence of statements separated by ';' we execute the individ- 
ual statements one after the other and from left to right. 

• To execute a statement consisting of a variable followed by ':=' and another 
variable we determine the value of the second variable and assign it to the 
first variable. 

We shall record the execution of the example program in a state where x has the 
value 5, y the value 7 and z the value by the following "derivation sequence": 
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(z:=x; x:=y; y 

(x:=y; y 

(y 



=z, [xh-)-5, y>->-7, zh-)-0]} 
=z, [xi->5, yH>7, zi-^5]) 
=z, [xi-^7, yH>7, zi-^5]) 
[xi-^7, yH>5, zh-)-5] 



In the first step we execute the statement z:=x and the value of z is changed 
to 5 whereas those of x and y are unchanged. The remaining program is now 
x:= y; y :=z - After the second step the value of x is 7 and we are left with the 
program y:=z. The third and final step of the computation will change the value 
of y to 5. Therefore the initial values of x and y have been exchanged, using z as 
a temporary variable. 

This explanation gives an abstraction of how the program is executed on a 
machine. It is important to observe that it is indeed an abstraction: we ignore 
details like use of registers and addresses for variables. So the operational semantics 
is rather independent of machine architectures and implementation strategies. 

In Chapter 2 we shall formalize this kind of operational semantics which is often 
called structural operational semantics (or small-step semantics). An alternative 
operational semantics is called natural semantics (or big-step semantics) and differs 
from the structural operational semantics by hiding even more execution details. 
In the natural semantics the execution of the example program in the same state 
as before will be represented by the following "derivation tree" : 

(z:=x, s ) -> si (x:=y, Si) -> s 2 



(z:=x; x:=y, s ) -> s 2 {Y'-= z , s ?) ~> s 3 

(z:=x; x:=y; y:=z, s ) -> s 3 

where we have used the abbreviations: 
so = [xh>5, yH>7, zi->0] 
si = [xi->5, yi— >7, zi->5] 
,5 2 = [xh>7, yn-^7, zi->5] 
53 = [xi->7, yi— >5, zi->5] 

This is to be read as follows: The execution of z:=x in the state s will result in 
the state si and the execution of x:=y in state si will result in state s 2 . Therefore 
the execution of z:=x; x:=y in state s will give state s 2 . Furthermore, execution 
of y:=z in state s 2 will give state s 3 so in total the execution of the program in 
state so will give the resulting state s 3 . This is expressed by 



(z:=x; x:=y; y:=z, s ) -> s 3 
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but now we have hidden the above explanation of how it was actually obtained. 

In Chapter 3 we shall use the natural semantics as the basis for proving the 
correctness of an implementation of a simple programming language. 

Denotational semantics (Chapter 4) 

In the denotational semantics we concentrate on the effect of executing the pro- 
grams and we shall model this by mathematical functions: 

• The effect of a sequence of statements separated by ';' is the functional 
composition of the effects of the individual statements. 

• The effect of a statement consisting of a variable followed by ':=' and another 
variable is the function that given a state will produce a new state: it is as 
the original one except that the value of the first variable of the statement 
is equal to that of the second variable. 

For the example program we obtain functions written <S[z:=x], <S[x:=y], and 
5[y:=z] for each of the assignment statements and for the overall program we 
get the function 

<S[z:=x; x:=y; y:=z] = <%:=zj o <Slx:=y] o <S[z:=x] 

Note that the order of the statements have changed because we use the usual 
notation for function composition where (/ o g) s means / (g s). If we want to 
determine the effect of executing the program on a particular state then we can 
apply the function to that state and calculate the resulting state as follows: 

<S[z:=x; x:=y; y:=z]([x^5, y^7, zH-O]) 

= (S[y:=z] o 5[x:=y] o <S[z:=x])([x^5, y^7, z->0]) 
= S[y:=z](S[x:=y](<S[z:=x]([x^5, y^7, z->0]))) 
= <%:=z](<S[x:=y]([x^5, y^7, z->5])) 
= <S[y:=z]([x^7, y^7, z^5]) 
= [xi->7, yi— >5, zi->5] 

Note that we are only manipulating mathematical objects; we are not concerned 
with executing programs. The difference may seem small for a program with only 
assignment and sequencing statements but for programs with more sophisticated 
constructs it is substantial. The benefits of the denotational approach are mainly 
due to the fact that it abstracts away from how programs are executed. Therefore 
it becomes easier to reason about programs as it simply amounts to reasoning 
about mathematical objects. However, a prerequisite for doing so is to establish a 
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firm mathematical basis for denotational semantics and this task turns out not to 
be entirely trivial. 

The denotational approach can easily be adapted to express other sorts of 
properties of programs. Some examples are: 

• Determine whether all variables are initialized before they are used — if not 
a warning may be appropriate. 

• Determine whether a certain expression in the program always evaluates to 
a constant — if so one can replace the expression by the constant. 

• Determine whether all parts of the program are reachable — if not they could 
as well be removed or a warning might be appropriate. 

In Chapter 5 we develop an example of this. 

While we prefer the denotational approach when reasoning about programs we 
may prefer an operational approach when implementing the language. It is there- 
fore of interest whether a denotational definition is equivalent to an operational 
definition and this is studied in Section 4.3. 



Axiomatic semantics (Chapter 6) 

Often one is interested in partial correctness properties of programs: A program is 
partially correct, with respect to a precondition and a postcondition, if whenever 
the initial state fulfils the precondition and the program terminates, then the final 
state is guaranteed to fulfil the postcondition. For our example program we have 
the partial correctness property: 

{ x=n A y=m } z:=x; x:=y; y:=z { y=n A x=m } 

where x=n A y=m is the precondition and y=n A x=m is the postcondition. The 
names n and m are used to "remember" the initial values of x and y, respectively. 
The state [xi->5, yi— >7, zh->0] satisfies the precondition by taking n=5 and m=7 and 
when we have proved the partial correctness property we can deduce that if the 
program terminates then it will do so in a state where y is 5 and x is 7. However, 
the partial correctness property does not ensure that the program will terminate 
although this is clearly the case for the example program. 

The axiomatic semantics provides a logical system for proving partial correct- 
ness properties of individual programs. A proof of the above partial correctness 
property may be expressed by the following "proof tree" : 
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{ po } z:=x { pi } 



{ Pi } x:=y { p 2 } 



{p } z:=x; x:=y { p 2 } 



{ p 2 } y:=z { p 3 } 



{p } z:=x; x:=y; y:=z { p 3 } 



where we have used the abbreviations 



Po 


— x=n A y 


Pi 


= z=n A y 


P2 


= z=n A x 


P3 


= y=n A x 



We may view the logical system as a specification of only certain aspects of the 
semantics. It usually does not capture all aspects for the simple reason that all the 
partial correctness properties listed below can be proved using the logical system 
but certainly we would not regard the programs as behaving in the same way: 

{ x=n A y=m } z:=x; x:=y; y:=z { y=n A x=m } 

{ x=n A y=m } if x=y then skip else (z:=x; x:=y; y:=z) { y=n A x=m } 

{ x=n A y=m } while true do skip { y=n A x=m } 

The benefits of the axiomatic approach are that the logical systems provide an easy 
way of proving properties of programs — and to a large extent it has been possible 
to automate it. Of course this is only worthwhile if the axiomatic semantics is 
faithful to the "more general" (denotational or operational) semantics we have in 
mind and we shall discuss this in Section 6.3. 

The complementary view 

It is important to note that these kinds of semantics are not rival approaches, but 
are different techniques appropriate for different purposes and — to some extent - 
for different programming languages. To stress this, the development will address 
the following issues: 

• It will develop each of the approaches for a simple language of while- 



• It will illustrate the power and weakness of each of the approaches by ex- 
tending the while-language with other programming constructs. 

• It will prove the relationship between the approaches for the while- language. 



programs. 
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• It will give examples of applications of the semantic descriptions in order to 
illustrate their merits. 

1.2 The example language While 

This book illustrates the various forms of semantics on a very simple imperative 
programming language called While. As a first step we must specify its syntax. 

The syntactic notation we use is based on BNF. First we list the various syntac- 
tic categories and give a meta- variable that will be used to range over constructs of 
each category. For our language the meta-variables and categories are as follows: 

n will range over numerals, Num, 

x will range over variables, Var, 

a will range over arithmetic expressions, Aexp, 

b will range over boolean expressions, Bexp, and 

S will range over statements, Stm. 

The meta-variables can be primed or subscripted. So, for example, n, n ! , ni, n 2 
all stand for numerals. 

We assume that the structure of numerals and variables is given elsewhere; for 
example numerals might be strings of digits, and variables strings of letters and 
digits starting with a letter. The structure of the other constructs is: 

a ::= n | x | oi + a 2 | «i * a 2 | «i — a 2 
b ::= true | false | oi = a 2 | «i < «2 | — ■ 6 | hi A b 2 
S ::= x := a | skip | S\ ; S 2 | if b then S\ else S 2 
while b do S 

Thus, a boolean expression b can only have one of six forms. It is called a basis 
element if it is true or false or has the form a\ = a2 or a\ < a2 where a\ and 02 
are arithmetic expressions. It is called a composite element if it has the form -16 
where b is a boolean expression, or the form b\ A b 2 where bi and b 2 are boolean 
expressions. Similar remarks apply to arithmetic expressions and statements. 

The specification above defines the abstract syntax of While in that it simply 
says how to build arithmetic expressions, boolean expressions and statements in 
the language. One way to think of the abstract syntax is as specifying the parse 
trees of the language and it will then be the purpose of the concrete syntax to 
provide sufficient information that enable unique parse trees to be constructed. 

So given the string of characters: 



z: =x; x:=y; y:=z 
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In this book we shall not be concerned with concrete syntax. Whenever we talk 
about syntactic entities such as arithmetic expressions, boolean expressions or 
statements we will always be talking about the abstract syntax so there is no 
ambiguity with respect to the form of the entity. In particular, the two trees 
above are both elements of the syntactic category Stm. 

It is rather cumbersome to use the graphical representation of abstract syntax 
and we shall therefore use a linear notation. So we shall write 

z: =x; (x:=y; y:=z) 

for the leftmost syntax tree and 

(z:=x; x:=y); y:=z 

for the rightmost one. For statements one often writes the brackets as begin • • • 
end but we shall feel free to use ( • • • ) in this book. Similarly, we use brackets 
( • • • ) to resolve ambiguities for elements in the other syntactic categories. To cut 
down on the number of brackets needed we shall allow to use the familiar relative 
binding powers (precedences) of +, * and — etc. and so write l+x*2 for l+(x*2) 
but not for (l+x)*2. 

Exercise 1.1 The following statement is in While: 

y:=l; while -i(x=l) do (y:=y*x; x:=x— l) 

It computes the factorial of the initial value bound to x (provided that it is positive) 
and the result will be the final value of y. Draw a graphical representation of the 
abstract syntax tree. □ 



1.3 Semantics of expressions 
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Exercise 1.2 Assume that the initial value of the variable x is n and that the 
initial value of y is m. Write a statement in While that assigns z the value of n 
to the power of m, that is 

n * • • • * n 
\ y j 

m times 

Give a linear as well as a graphical representation of the abstract syntax. □ 

The semantics of While is given by defining so-called semantic functions for 
each of the syntactic categories. The idea is that a semantic function takes a 
syntactic entity as argument and returns its meaning. The operational, denota- 
tional and axiomatic approaches mentioned earlier will be used to specify semantic 
functions for the statements of While. For numerals, arithmetic expressions and 
boolean expressions the semantic functions are specified once and for all below. 

1.3 Semantics of expressions 

Before embarking on specifying the semantics of the arithmetic and boolean ex- 
pressions of While let us have a brief look at the numerals; this will present the 
main ingredients of the approach in a very simple setting. So assume for the mo- 
ment that the numerals are in the binary system. Their abstract syntax could 
then be specified by: 

n ::= | 1 | n | n 1 

In order to determine the number represented by a numeral we shall define a 
function 

AT: Num ->• Z 

This is called a semantic function as it defines the semantics of the numerals. We 
want A/" to be a total function because we want to determine a unique number 
for each numeral of Num. If n E Num then we write A/"[n] for the application 
of M to n, that is for the corresponding number. In general, the application of 
a semantic function to a syntactic entity will be written within the "syntactic" 
brackets '[' and ']' rather than the more usual '(' and ')'. These brackets have no 
special meaning but throughout this book we shall enclose syntactic arguments to 
semantic functions using the "syntactic" brackets whereas we use ordinary brackets 
(or juxtapositioning) in all other cases. 

The semantic function J\f is defined by the following semantic clauses (or equa- 
tions): 
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A/Il] 
N{n 0] 

M{n 1] 



= 



= 1 



2 ★ M\n\ 

2 ★ A/"[n] + 1 



Here and 1 are numbers, that is elements of Z. Furthermore, ★ and + are the 
usual arithmetic operations on numbers. The above definition is an example of a 
compositional definition; this means that for each possible way of constructing a 
numeral it tells how the corresponding number is obtained from the meanings of 
the sw&constructs. 

Example 1.3 We can calculate the number A/"[l0l] corresponding to the numeral 
101 as follows: 

AA[101] = 2*AA[10] + 1 

= 2 ★ (2 ★ M{1\) + 1 
= 2 ★ (2 ★ 1) + 1 
= 5 

Note that the string 101 is decomposed according to the syntax for numerals. □ 

So far we have only claimed that the definition of N gives rise to a well-defined 
total function. We shall now present a formal proof showing that this is indeed 
the case. 



Fact 1.4 The above equations for J\f, define a total function J\f: Num — > Z. 



Proof: We have a total function JV, if for all arguments n G Num 

there is exactly one number n e Z such that A/"[n] = n (*) 

Given a numeral n it can have one of four forms: it can be a basis element and 
then it is equal to or 1, or it can be a composite element and then it is equal to 
n'O or n'l for some other numeral n' . So, in order to prove (*) we have to consider 
all four possibilities. 

The proof will be conducted by induction on the structure of the numeral n. 
In the base case we prove (*) for the basis elements of Num, that is for the cases 
where n is or 1. In the induction step we consider the composite elements of 
Num, that is the cases where n is n'O or n'l. The induction hypothesis will then 
allow us to assume that (*) holds for the immediate constituent of n, that is n'. 
We shall then prove that (*) holds for n. It then follows that (*) holds for all 
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numerals n because any numeral n can be constructed in that way. 

The case n = 0: Only one of the semantic clauses defining J\f can be used and it 
gives A/"[n] = 0. So clearly there is exactly one number n in Z (namely 0) such 
that JV[n] = n. 

The case n = 1 is similar and we omit the details. 

The case n = n'0: Inspection of the clauses defining J\f shows that only one of 
the clauses is applicable and we have A/"[n] = 2 ★ A/"[n']. We can now apply 
the induction hypothesis to n' and get that there is exactly one number n' such 
that A/"[n'] = n'. But then it is clear that there is exactly one number n (namely 
2 ★ n') such that A/"[n] = n. 

The case n = n'l is similar and we omit the details. □ 

The general technique that we have applied in the definition of the syntax and 
semantics of numerals can be summarized as follows: 



Compositional Definitions 



1: The syntactic category is specified by an abstract syntax giving the basis 
elements and the composite elements. The composite elements have a 
unique decomposition into their immediate constituents. 

2: The semantics is defined by compositional definitions of a function: There 
is a semantic clause for each of the basis elements of the syntactic category 
and one for each of the methods for constructing composite elements. The 
clauses for composite elements are defined in terms of the semantics of the 
immediate constituents of the elements. 



The proof technique we have applied is closely connected with the approach to 
defining semantic functions. It can be summarized as follows: 



Structural Induction 



1: Prove that the property holds for all the basis elements of the syntactic 
category. 

2: Prove that the property holds for all the composite elements of the syn- 
tactic category: Assume that the property holds for all the immediate 
constituents of the element (this is called the induction hypothesis) and 
prove that it also holds for the element itself. 



In the remainder of this book we shall assume that numerals are in decimal 
notation and have their normal meanings (so for example A/"[137] = 137 e Z). It 
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is important to understand, however, that there is a distinction between numerals 
(which are syntactic) and numbers (which are semantic), even in decimal notation. 

Semantic functions 

The meaning of an expression depends on the values bound to the variables that 
occur in it. For example, if x is bound to 3 then the arithmetic expression x+1 
evaluates to 4 but if x is bound to 2 then the expression evaluates to 3. We shall 
therefore introduce the concept of a state: to each variable the state will associate 
its current value. We shall represent a state as a function from variables to values, 
that is an element of the set 

State = Var -> Z 

Each state s specifies a value, written s x, for each variable x of Var. Thus if 
s x = 3 then the value of x+1 in state s is 4. 

Actually, this is just one of several representations of the state. Some other 
possibilities are to use a table: 



X 


5 


y 


7 


z 






or a "list" of the form 
[xh>5, yH>7, zh>0] 

(as in Section 1.1). In all cases we must ensure that exactly one value is associated 
with each variable. By requiring a state to be a function this is trivially fulfilled 
whereas for the alternative representations above extra restrictions have to be 
enforced. 

Given an arithmetic expression a and a state s we can determine the value of 
the expression. Therefore we shall define the meaning of arithmetic expressions 
as a total function A that takes two arguments: the syntactic construct and the 
state. The functionality of A is 

A: Aexp ->■ (State ->■ Z) 

This means that A takes its parameters one at a time. So we may supply A with 
its first parameter, say x+1, and study the function *4|x+l]. It has functionality 
State — > Z and only when we supply it with a state (which happens to be a 
function but that does not matter) do we obtain the value of the expression x+1. 

Assuming the existence of the function N defining the meaning of numerals, we 
can define the function A by defining its value -4[a]s on each arithmetic expression 
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Alnjs 


= -A/ [raj 




= S X 


Afa\ + a 2 Js 


= AlaAs + *4ja 2 1s 


A\ai * a 2 js 


= ^4[oi]a ★ A[a 2 ]<s 


A{ai - a 2 js 


= A[cn\s - Ala 2 }s 


Table 1.1 


The semantics of arithmetic expressions 



a and state s. The definition of A is given in Table 1.1. The clause for n reflects 
that the value of n in any state is A/"[n]. The value of a variable x in state s is the 
value bound to x in s, that is s x. The value of the composite expression ai+a 2 
in s is the sum of the values of ai and a 2 in s. Similarly, the value of ai * a 2 in s 
is the product of the values of ai and a 2 in 5, and the value of ai — a 2 in s is the 
difference between the values of a\ and a 2 in s. Note that + , * and — occurring 
on the right of these equations are the usual arithmetic operations, whilst on the 
left they are just pieces of syntax; this is analogous to the distinction between 
numerals and numbers but we shall not bother to use different symbols. 

Example 1.5 Suppose that s x = 3. Then: 

A[x+l]s = Afxjs + A[l]s 
= (sx)+Af{l] 
= 3 + 1 
= 4 

Note that here 1 is a numeral (enclosed in the brackets '[' and ']') whereas 1 is a 
number. □ 



Example 1.6 Suppose we add the arithmetic expression — a to our language. An 
acceptable semantic clause for this construct would be 

A{- ajs = - A[a\s 

whereas the alternative clause A\— a\s = A\0 — ajs would contradict the com- 
positionality requirement. □ 

Exercise 1.7 Prove that the equations of Table 1.1 define a total function A 
in Aexp — > (State — > Z): First argue that it is sufficient to prove that for 
each a e Aexp and each s G State there is exactly one value v e Z such that 
•AJafs = v. Next use structural induction on the arithmetic expressions to prove 
that this is indeed the case. □ 
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if ^4[oi]a = -4[a 2 ]s 
if^[oi]a^^[o 2 ]a 
if >l[oi]a < A{a 2 ]s 
XAMs > A{a 2 ]s 
if B[b]s = ff 
if B[b]s = tt 

if = tt and B[b 2 \s = tt 

if B[6i]a = ff or £[6 2 ]s = ff 

Table 1.2: The semantics of boolean expressions 

The values of boolean expressions are truth values so in a similar way we shall 
define their meanings by a (total) function from State to T: 

B: Bexp -> (State -> T) 

Here T consists of the truth values tt (for true) and ff (for false). 

Using A we can define B by the semantic clauses of Table 1.2. Again we have 
the distinction between syntax (e.g. < on the left-hand side) and semantics (e.g. 
< on the right-hand side). 

Exercise 1.8 Assume that s x = 3 and determine B[-i(x = □ 

Exercise 1.9 Prove that the equations of Table 1.2 define a total function B in 
Bexp -> (State -> T). □ 

Exercise 1.10 The syntactic category Bexp' is defined as the following extension 
of Bexp: 

b ::= true | false | a\ = a 2 | a\ ^ a 2 \ a\ < a 2 | oi > a 2 
oi < a 2 | oi > a 2 | — ■ 6 | b\ A 5 2 | b\ V 6 2 
I 6i ^ 2 | 6i <^ b 2 

Give a compositional extension of the semantic function B of Table 1.2. 
Two boolean expressions b\ and b 2 are equivalent if for all states s, 

Blb^s = B{b 2 \s 

Show that for each b' of Bexp' there exists a boolean expression b of Bexp such 
that b' and b are equivalent. □ 



£[true]s = tt 
£[false]s = ff 



#[ai = a 2 \s 
B\ai < a 2 js 

Bib, A b 2 js 



I 
I 



tt 
ff 
tt 
ff 



I 

tt 
ff 



I 

tt 
ff 
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1.4 Properties of the semantics 

Later in the book we shall be interested in two kinds of properties for expressions. 
One is that their values do not depend on values of variables that do not occur 
in them. The other is that if we replace a variable with an expression then we 
could as well have made a similar change in the state. We shall formalize these 
properties below and prove that they do hold. 

Free variables 

The free variables of an arithmetic expression a is defined to be the set of variables 
occurring in it. Formally, we may give a compositional definition of the subset 
FV(a)ofVar: 



FV(oi + o 2 ) = FV(oi) U FV(a 2 ) 
FV(oi * a 2 ) = FV(oi) U FV(a 2 ) 
FV(oi - a 2 ) = FV(oi) U FV(a 2 ) 

As an example FV(x+l) = { x } and FV(x+y*x) = { x, y }. It should be obvious 
that only the variables in FV(o) may influence the value of a. This is formally 
expressed by: 



Lemma 1.11 Let s and s' be two states satisfying that s x = s' x for all x in 
FV(o). Then A{a]s = A{a]s'. 



Proof: We shall give a fairly detailed proof of the lemma using structural induction 
on the arithmetic expressions. We shall first consider the basis elements of Aexp: 

The case n: From Table 1.1 we have -4|n]<s = A/"[n] as well as *4|n]s' = A/"[n]. 
So *4|n]s = ^4[n]5 ; and clearly the lemma holds in this case. 

The case x: From Table 1.1 we have -4[a;]s = s x as well as ^.[xjs' — s' x. From 
the assumptions of the lemma we get s x = s' x because x e FV(x) so clearly the 
lemma holds in this case. 

Next we turn to the composite elements of Aexp: 

The case oi + a 2 : From Table 1.1 we have A\a\ + a 2 js = *4|ai]s + -4|s 2 ]s and 
similarly A\a\ + a 2 ]s' = ^[aijs' + *4Js 2 ]]s'. Since Oi (for i = 1,2) is an immediate 
subexpression of oi + a 2 and FV(oi) C FV(oi + a 2 ) we can apply the induction 
hypothesis (that is the lemma) to Oi and get -4[aj]s = ^4[aj]s'. It is now easy to 



FV(n) 
FV(x) 





{x} 
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see that the lemma holds for oi + a 2 as well. 

The cases oi — a 2 and oi * a 2 follow the same pattern and are omitted. This 
completes the proof. □ 

In a similar way we may define the set FV(6) of free variables in a boolean 
expression b by 

FV(true) = 

FV(false) = 

FV(oi = o 2 ) = FV(oi) U FV(a 2 ) 

FV(oi < o 2 ) = FV(oi) U FV(a 2 ) 

FV(^6) = FV(6) 

FV(6i A 6 2 ) = FV(6i) U FV(b 2 ) 

Exercise 1.12 (Essential) Let s and s' be two states satisfying that s x = s' x 
for all x in FV(6). Prove that B\b\s = B[b\s' '. □ 

Substitutions 

We shall later be interested in replacing each occurrence of a variable y in an 
arithmetic expression a with another arithmetic expression do- This is called 
substitution and we write a[y^a ] for the arithmetic expression so obtained. The 
formal definition is as follows: 

n[y^a ] = n 

{ao if x = y 
x it x 7= y 

(oi + a 2 )[y^a ] = (oi[i/i->oo]) + (a 2 [yH>a ]) 
(ai * a 2 )[yH>a ] = (ai[yH>a ]) * (a 2 [y^a ]) 
(at - a 2 )[y^a ] = (ai[yH>a ]) - (^[y^ao]) 

As an example (x+l)[xi->3] = 3+1 and (x+y*x) [xH>y— 5] = (y— 5)+y*(y— 5). 

We also have a notion of substitution (or updating) for states. We define 
s [y *->v] to be the state that is as s except that the value bound to y is v, that is 



(s[j/i-H) x 



r if x = y 
s x if x ^ y 

The relationship between the two concepts is shown in the following exercise: 
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Exercise 1.13 (Essential) Prove that *4|a[yi->-ao]]<s = *4.[a](s[yi->-.4|ao]]<s]) for 
all states s. □ 

Exercise 1.14 (Essential) Define substitution for boolean expressions: b[y>- >-a ] 
is to be the boolean expression that is as b except that all occurrences of the 
variable y are replaced by the arithmetic expression a . Prove that your definition 
satisfies 

Blb[y^a ]js = Blb}(s[y^Ala }s]) 



for all states s. 



□ 
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Chapter 2 

Operational Semantics 



The role of a statement in While is to change the state. For example, if x is bound 
to 3 in s and we execute the statement x := x + 1 then we get a new state where x 
is bound to 4. So while the semantics of arithmetic and boolean expressions only 
inspect the state in order to determine the value of the expression, the semantics 
of statements will modify the state as well. 

In an operational semantics we are concerned with how to execute programs 
and not merely what the results of execution are. More precisely, we are interested 
in how the states are modified during the execution of the statement. We shall 
consider two different approaches to operational semantics: 

• Natural semantics: its purpose is to describe how the overall results of exe- 
cutions are obtained. 

• Structural operational semantics: its purpose is to describe how the individual 
steps of the computations take place. 

We shall see that for the language While we can easily specify both kinds of 
semantics and that they will be "equivalent" in a sense to be made clear later. 
However, we shall also give examples of programming constructs where one of the 
approaches is superior to the other. 

For both kinds of operational semantics, the meaning of statements will be 
specified by a transition system. It will have two types of configurations: 

(5, s) representing that the statement S is to be executed from 
the state s, and 

s representing a terminal (that is final) state. 

The terminal configurations will be those of the latter form. The transition relation 
will then describe how the execution takes place. The difference between the two 
approaches to operational semantics amounts to different ways of specifying the 
transition relation. 
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[ass ns ] 


(x := a, a) — > s[x>- >Alajs] 




[skip ns ] 


(skip, a) — > a 




[comp ns ] 


(Si, s) ->• 5', (S 2 , 5') ->• 5" 

<5i;5 2 , a) -> a" 




ra 


<5i, 5) -> a' 

\ J. 5 / 

(if 6 then 5i else S2, s) — >■ a' 


if = tt 




(if 6 then Si else ^2, a) — > s' 


if £[6]s = ff 


[while**] 


{S, a) -> a', (while 6 do 5, a') 
(while 6 do 5, a) -> a" 


-> a" 

if B[6]a = tt 


[while n ff s ] 


(while 6 do S, a) -> a if B[b]s 


= ff 



Table 2.1: Natural semantics for While 



2.1 Natural semantics 

In a natural semantics we are concerned with the relationship between the initial 
and the final state of an execution. Therefore the transition relation will specify 
the relationship between the initial state and the final state for each statement. 
We shall write a transition as 

(S, a) -> a' 

Intuitively this means that the execution of S from a will terminate and the re- 
sulting state will be a'. 

The definition of — > is given by the rules of Table 2.1. A rule has the general 
form 

{Si, Si) —> s[, • • -, (S n , a n ) — > s' n ^ 
(S, a) a' 

where Si, ■ ■ ■, S n are immediate constituents of S or are statements constructed 
from the immediate constituents of S. A rule has a number of premises (written 
above the solid line) and one conclusion (written below the solid line). A rule may 
also have a number of conditions (written to the right of the solid line) that have 
to be fulfilled whenever the rule is applied. Rules with an empty set of premises 
are called axioms and the solid line is then omitted. 

Intuitively, the axiom [ass ns ] says that in a state a, x := a is executed to yield 
a final state a[:rH^4[[a]]a] which is as a except that x has the value *4|a]a. This 
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is really an axiom schema because x, a and s are meta- variables standing for 
arbitrary variables, arithmetic expressions and states but we shall simply use the 
term axiom for this. We obtain an instance of the axiom by selecting particular 
variables, arithmetic expressions and states. As an example, if s is the state that 
assigns the value to all variables then 

(x := x+1, s ) — > s [x\-^l] 

is an instance of [ass ns ] because x is instantiated to x, a to x+1, s to s , and the 
value *4|x+l]s is determined to be 1. 

Similarly [skip ns ] is an axiom and, intuitively, it says that skip does not change 
the state. Letting s be as above we obtain 

(skip, so) -> s 

as an instance of the axiom [skip ns ]. 

Intuitively, the rule [comp ns ] says that to execute Si,S 2 from state s we must 
first execute Si from s. Assuming that this yields a final state s' we shall then 
execute S 2 from s'. The premises of the rule are concerned with the two statements 
Si and S 2 whereas the conclusion expresses a property of the composite statement 
itself. The following is an instance of the rule: 

(skip, s ) -> s Q , (x := x+1, s ) -> s [xi-)-l] 

(skip; x := x+1, s ) — > s [xi-)-l] 

Here Si is instantiated to skip, S 2 to x := x + 1, s and s' are both instantiated 
to s and s" is instantiated to s [xi->-1]. Similarly 

(skip, s ) — >■ s [xi-)-5], (x := x+1, s [xH>5]) — > s 

(skip; x := x+1, s ) — > s 

is an instance of [comp ns ] although it is less interesting because its premises can 
never be derived from the axioms and rules of Table 2.1. 

For the if -construct we have two rules. The first one, [if**], says that to execute 
if b then Si else S 2 we simply execute Si provided that b evaluates to tt in 
the state. The other rule, [ifjfj, says that if b evaluates to ff then to execute 
if b then Si else S 2 we just execute S 2 . Taking s x = the following is an 
instance of the rule [if**]: 

(skip, s ) -> s 
(if x = then skip else x := x+1, So) — >■ So 

because B{x — 0]s = tt. However, had it been the case that s x then it 
would not be an instance of the rule [if**] because then B{x = 0]s would amount 
to ff. Furthermore it would not be an instance of the rule [if„ s ] because the premise 
has the wrong form. 
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Finally, we have one rule and one axiom expressing how to execute the while- 
construct. Intuitively, the meaning of the construct while b do S in the state s 
can be explained as follows: 

• If the test b evaluates to true in the state s then we first execute the body of 
the loop and then continue with the loop itself from the state so obtained. 

• If the test b evaluates to false in the state s then the execution of the loop 
terminates. 

The rule [while**] formalizes the first case where b evaluates to tt and it says 
that then we have to execute S followed by while b do S again. The axiom 
[whilefg] formalizes the second possibility and states that if b evaluates to ff then 
we terminate the execution of the while-construct leaving the state unchanged. 
Note that the rule [while**] specifies the meaning of the while-construct in terms 
of the meaning of the very same construct so that we do not have a compositional 
definition of the semantics of statements. 

When we use the axioms and rules to derive a transition (5, s) — > s' we obtain 
a derivation tree. The root of the derivation tree is (S, s) — > s' and the leaves 
are instances of axioms. The internal nodes are conclusions of instantiated rules 
and they have the corresponding premises as their immediate sons. We request 
that all the instantiated conditions of axioms and rules must be satisfied. When 
displaying a derivation tree it is common to have the root at the bottom rather 
than at the top; hence the son is above its father. A derivation tree is called simple 
if it is an instance of an axiom, otherwise it is called composite. 

Example 2.1 Let us first consider the statement of Chapter 1: 
(z:=x; x:=y); y:=z 

Let s be the state that maps all variables except x and y to and has s x = 5 
and s y = 7. Then the following is an example of a derivation tree: 

(z:=x, s ) -> si (x:=y, Si) -> s 2 



(z:=x; x:=y, s ) -> s 2 {Y'-= z , s 2) -> s 3 



((z:=x; x:=y); y:=z, a > -> s 3 
where we have used the abbreviations: 
si = so[zh- >5] 
s 2 = si[xi-^7] 
S3 = s2[y->5] 
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The derivation tree has three leaves denoted (z:=x, s ) — > si, (x:=y, si) —> s 2 , 
and (y:=z, s 2 ) — >■ s 3 , corresponding to three applications of the axiom [ass ns ]. The 
rule [compns] has been applied twice. One instance is 

(z:=x, s ) -> si, (x:=y, Si) -> s 2 

(z:=x; x:=y, s ) -> <s 2 

which has been used to combine the leaves (z:=x, s ) — > Si and (x:=y, si) — >■ s 2 
with the internal node labelled (z:=x; x:=y, s ) — >■ s 2 . The other instance is 

(z:=x; x:=y, s ) -> «2, (y:=z, s 2 ) -> ^3 

((z:=x; x:=y); y:=z, a > -> s 3 

which has been used to combine the internal node (z:=x; x:=y, s ) — > s 2 and the 
leaf (y:=z, s 2 ) — > S3 with the root ((z:=x; x:=y); y:=z, s ) ~ ^ S3. □ 

Consider now the problem of constructing a derivation tree for a given state- 
ment S and state s. The best way to approach this is to try to construct the 
tree from the root upwards. So we will start by finding an axiom or rule with a 
conclusion where the left-hand side matches the configuration {S : s). There are 
two cases: 

• If it is an axiom and if the conditions of the axiom are satisfied then we 
can determine the final state and the construction of the derivation tree is 
completed. 

• If it is a rule then the next step is to try to construct derivation trees for the 
premises of the rule. When this has been done, it must be checked that the 
conditions of the rule are fulfilled, and only then can we determine the final 
state corresponding to (5, s). 

Often there will be more than one axiom or rule that matches a given configuration 
and then the various possibilities have to be inspected in order to find a derivation 
tree. We shall see later that for While there will be at most one derivation tree 
for each transition (5, s) — > s' but that this need not hold in extensions of While. 

Example 2.2 Consider the factorial statement: 

y:=l; while -i(x=l) do (y:=y * x; x:=x— l) 

and let s be a state with s x = 3. In this example we shall show that 

(y:=l; while -i(x=l) do (y:=y * x; x:=x-l), s) ->■ s[yH>6][xH>l] (*) 

To do so we shall show that (*) can be obtained from the transition system of 
Table 2.1. This is done by constructing a derivation tree with the transition (*) 
as its root. 

Rather than presenting the complete derivation tree T in one go, we shall build 
it in an upwards manner. Initially, we only know that the root of T is of the form: 
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(y:=l; while -i(x=l) do (y:=y * x; x:=x— l), s) — > s 6 i 

However, the statement 

y:=l; while -i(x=l) do (y:=y * x; x:=x— l) 

is of the form Si; S 2 so the only rule that could have been used to produce the 
root of T is [compng]. Therefore T must have the form: 

(y:=l, a)->a 13 Ti 

(y:=l; while -i(x=l) do (y:=y*x; x:=x— l), s)— >s e i 

for some state Si 3 and some derivation tree Ti which has root 

(while -n(x=l) do (y:=y*x; x:=x-l), s 13 )->s 61 (**) 

Since (y:=l, s) — > Si 3 has to be an instance of the axiom [ass ns ] we get that Si 3 = 
a[yi->l]. 

The missing part Ti of T is a derivation tree with root (**). Since the state- 
ment of (**) has the form while b do S the derivation tree T\ must have been 
constructed by applying either the rule [while**] or the axiom [while^]. Since 
jEJ[-i(x=l)]si3 = tt we see that only the rule [while**] could have been applied so 
Ti will have the form: 

T 2 T 3 

(while -i(x=l) do (y:=y*x; x:=x— l), Si 3 } — >sqi 
where T 2 is a derivation tree with root 

(y:=y*x; x:=x-l, Si 3 )->s 32 
and T 3 is a derivation tree with root 

(while ->(x=l) do (y:=y*x; x:=x-l), s 32 )->-s 6 i (***) 
for some state s 32 . 

Using that the form of the statement y:=y*x; x:=x— 1 is Si;S 2 it is now easy 
to see that the derivation tree T 2 is 

(y:=y*x, <Si 3 )^s 33 (x:=x-l, s 33 )->-s 32 

(y:=y*x; x:=x-l, Si 3 )-^ 32 

where s 33 = s[yi->3] and s 32 = s[yi->3][xi->2]. The leaves of T 2 are instances of 
[ass ns ] and they are combined using [comp ns ]. So now T 2 is fully constructed. 

In a similar way we can construct the derivation tree T 3 with root (***) and 
we get: 
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(y:=y*x, s 32 )^-s 62 



(x:=x-l, S 62 )->S 61 



(y:=y*x; x:=x-l, s 32 )-^s 61 



r 4 



(while -i(x=l) do (y:=y*x; x:=x 



1), s 32 )^s 61 



where s$ 2 = s[yi->-6][xi->-2], s 6 i = s[yH>6][xH>l] and T 4 is a derivation tree with 
root 

(while -i(x=l) do (y:=y*x; x:=x— l), Sqi) — >Sqi 

Finally, we see that the derivation tree T 4 is an instance of the axiom [while^] 
because #[-i(x=l)]<s 6 i = ff- This completes the construction of the derivation tree 



Exercise 2.3 Consider the statement 

z:=0; while y<x do (z:=z+l; x:=x— y) 
Construct a derivation tree for this statement when executed in a state where x 



We shall introduce the following terminology: The execution of a statement S 
on a state s 

• terminates if and only if there is a state s' such that (5, s) s', and 

• loops if and only if there is no state s' such that (5, s) — > s'. 

We shall say that a statement S always terminates if its execution on a state s 
terminates for all choices of s, and always loops if its execution on a state s loops 
for all choices of s. 

Exercise 2.4 Consider the following statements 

• while -i(x=l) do (y:=y*x; x:=x— l) 

• while l<x do (y:=y*x; x:=x— l) 

• while true do skip 

For each statement determine whether or not it always terminates and whether or 
not it always loops. Try to argue for your answers using the axioms and rules of 



T for (*). 



□ 



has the value 17 and y has the value 5. 



□ 



Table 2.1. 



□ 
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Properties of the semantics 

The transition system gives us a way of arguing about statements and their prop- 
erties. As an example we may be interested in whether two statements Si and S 2 
are semantically equivalent, by this we mean that for all states s and s' 

{Si, s) ->■ s' if and only if {S 2 , s) ->■ 5' 



Lemma 2.5 The statement 

while b do S 
is semantically equivalent to 

if b then (iS 1 ; while b do iS 1 ) else skip. 



Proof: The proof is in two stages. We shall first prove that if 

(while b do S, s) -> 5" (*) 

then 

(if b then (S; while 6 do 5) else skip, s) -> 5" (**) 

Thus, if the execution of the loop terminates then so does its one-level unfolding. 
Later we shall show that if the unfolded loop terminates then so will the loop itself; 
the conjunction of these results then prove the lemma. 

Because (*) holds we know that we have a derivation tree T for it. It can 
have one of two forms depending on whether it has been constructed using the 
rule [while**] or the axiom [while^]. In the first case the derivation tree T has the 
form: 

Ti T 2 



(while b do S, s) -> s" 

where Ti is a derivation tree with root (S, s)—>s' and T 2 is a derivation tree with 
root (while b do S, s')—>s". Furthermore, B{b]s = tt. Using the derivation trees 
Ti and T 2 as the premises for the rules [comp ns ] we can construct the derivation 
tree: 

Ti T 2 

{S; while b do S, s) -> s" 
Using that B{b}s = tt we can use the rule [if**] to construct the derivation tree 
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(5; while 6 do S, s) -> 5" 



(if 6 then (5; while 5 do 5) else skip, 5) — > s" 

thereby showing that (**) holds. 

Alternatively, the derivation tree T is an instance of [while„ s ]. Then B{b}s = fF 
and we must have that s"= s. So T simply is 

(while b do 5, s) — > s 

Using the axiom [skip ns ] we get a derivation tree 

(skip, s)->s" 

and we can now apply the rule [ifjfj to construct a derivation tree for (**): 

(skip, s) ->■ s" 



(if b then (S; while b do S) else skip, s) — > s" 

This completes the first part of the proof. 

For the second stage of the proof we assume that (**) holds and shall prove 
that (*) holds. So we have a derivation tree T for (**) and must construct one for 
(*). Only two rules could give rise to the derivation tree T for (**), namely [if**] 
or [ifjfj. In the first case, B{b}s = tt and we have a derivation tree T 1 with root 

(S; while b do S, s)^s" 

The statement has the general form ^i; S 2 and the only rule that could give this 
is [compns]. Therefore there are derivation trees T 2 and T 3 for 

(5, s)— >s', and 

(while b do S : a')->a" 

for some state s'. It is now straightforward to use the rule [while**] to combine T 2 
and T 3 to a derivation tree for (*). 

In the second case, B{b}s = ff and T is constructed using the rule [if£]. This 
means that we have a derivation tree for 

(skip, s)-ts" 

and according to axiom [skip ns ] it must be the case that s=s". But then we can 
use the axiom [while^] to construct a derivation tree for (*). This completes the 
proof. □ 
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Exercise 2.6 Prove that the two statements S 1 ;(S2]S 3 ) and (S 1 ;S2);S 3 are se- 
mantically equivalent. Construct a statement showing that Si;S 2 is not, in general, 
semantically equivalent to S 2 ]Si. □ 

Exercise 2.7 Extend the language While with the statement 
repeat S until b 

and define the relation — > for it. (The semantics of the repeat-construct is not 
allowed to rely on the existence of a while-construct in the language.) Prove 
that repeat S until b and S; if b then skip else (repeat S until b) are 
semantically equivalent. □ 

Exercise 2.8 Another iterative construct is 

for x := Oi to a 2 do S 

Extend the language While with this statement and define the relation — > for it. 
Evaluate the statement 

y:=l; for z:=l to x do (y:=y * x; x:=x— l) 

from a state where x has the value 5. Hint: You may need to assume that you 
have an "inverse" to N, so that there is a numeral for each number that may arise 
during the computation. (The semantics of the f or-construct is not allowed to 
rely on the existence of a while-construct in the language.) □ 

In the above proof we used Table 2.1 to inspect the structure of the derivation 
tree for a certain transition known to hold. In the proof of the next result we shall 
combine this with an induction on the shape of the derivation tree. The idea can 
be summarized as follows: 



Induction on the Shape of Derivation Trees 



1: Prove that the property holds for all the simple derivation trees by showing 
that it holds for the axioms of the transition system. 

2: Prove that the property holds for all composite derivation trees: For each 
rule assume that the property holds for its premises (this is called the 
induction hypothesis) and prove that it also holds for the conclusion of the 
rule provided that the conditions of the rule are satisfied. 



To formulate the theorem we shall say that the semantics of Table 2.1 is determin- 
istic if for all choices of S, s, s' and s" we have that 



{S, s) ->■ s' and {S, s) ->■ s" imply s' = s" 
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This means that for every statement 5 and initial state s we can uniquely determine 
a final state s' if (and only if) the execution of S terminates. 

Theorem 2.9 The natural semantics of Table 2.1 is deterministic. 

Proof: We assume that (5, s)—>s' and shall prove that 
if (S, s)^s" then s' = s". 

We shall proceed by induction on the shape of the derivation tree for (5, s)—>s'. 

The case [ass ns ]: Then 5 is x:=a and s' is s[a;i-h4|a]s]. The only axiom or rule 
that could be used to give (x:=a, s)—^s" is [ass ns ] so it follows that s" must be 
s [:ri->- *4| a] s] and thereby s' = s". 

The case [skip ns ]: Analogous. 

The case [comp ns ]: Assume that 

{Si,S 2 , s)->s' 

holds because 

(Si, s)->s and (5 2 , s )—^s' 

for some s . The only rule that could be applied to give (Si;S2, s)—>s" is [comp ns ] 
so there is a state si such that 

(Si, s)->si and (5 2 , si)->s" 

The induction hypothesis can be applied to the premise 5}— >s and from 
(iSi, <s)— >si we get 5 = Si. Similarly, the induction hypothesis can be applied to 
the premise (S 2: so)-+s' and from (52, s )— >s" we get s' = s" as required. 

The case [if**]: Assume that 

(if b then Si else 5 2 , s) — > s' 
holds because 

B[b]s = tt and (Si, a)->a' 

From = tt we get that the only rule that could be applied to give the 

alternative (if b then Si else 5 2 , 5) — >■ 5" is [if**]. So it must be the case that 

(Si, s) -+ s" 
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But then the induction hypothesis can be applied to the premise {Si, s) —> s' and 
from {Si, s) — > s" we get s' = s". 

The case [if^J: Analogous. 

The case [while**]: Assume that 

(while b do S, s) -> s' 

because 

B[h\s — tt, {S, s)-ts and (while b do S, s )-^s' 

The only rule that could be applied to give (while b do S, s) — > s" is [while**] 
because B{b]s — tt and this means that 

{S, s)—¥si and (while b do S, si) —> s" 

must hold for some si. Again the induction hypothesis can be applied to the 
premise {S, s}— >-so and from {S, s}— >Si we get sq = Si. Thus we have 

(while b do S, so)—>s' and (while b do S, so)—>s" 

Since (while b do S, so)^-s' is a premise of (the instance of) [while**] we can 
apply the induction hypothesis to it. From (while b do S, s )^-s" we therefore 
get s' = s" as required. 

The case [while^]: Straightforward. □ 

Exercise 2.10 * Prove that repeat S until b (as defined in Exercise 2.7) is 
semantically equivalent to S; while ->6 do S. Argue that this means that the 
extended semantics is deterministic. □ 

It is worth observing that we could not prove Theorem 2.9 using structural 
induction on the statement S. The reason is that the rule [while**] defines the 
semantics of while b do S in terms of itself. Structural induction works fine when 
the semantics is defined compositionally (as e.g. A and B in Chapter 1). But the 
natural semantics of Table 2.1 is not defined compositionally because of the rule 
[while**]. 

Basically, induction on the shape of derivation trees is a kind of structural 
induction on the derivation trees: In the base case we show that the property 
holds for the simple derivation trees. In the induction step we assume that the 
property holds for the immediate constituents of a derivation tree and show that 
it also holds for the composite derivation tree. 
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The semantic function <S 



ns 



The meaning of statements can now be summarized as a (partial) function from 
State to State. We define 

<S ns : Stm — > (State <^-> State) 
and this means that for every statement S we have a partial function 

Sns[S] e State State. 
It is given by 



s' if (S, s) -> s' 
undef otherwise 



Note that S ns is a well-defined partial function because of Theorem 2.9. The need 
for partiality is demonstrated by the statement while true do skip that always 
loops (see Exercise 2.4); we then have 

S ns [while true do skip] s = undef 

for all states s. 

Exercise 2.11 The semantics of arithmetic expressions is given by the function 
A. We can also use an operational approach and define a natural semantics for 
the arithmetic expressions. It will have two kinds of configurations: 

(a, s) denoting that a has to be evaluated in state s, and 
z denoting the final value (an element of Z). 

The transition relation — >- Ae xp has the form 

(a, s) ->Aexp Z 

where the idea is that a evaluates to z in state s. Some example axioms and rules 
are 

(n, s) ->Aex P A/"[n] 

(Oi, S) -)"Aexp Z U (a 2 , S) -)"Aexp Z 2 
(Oi + 2 , S) ->Aexp Z 



where z = Z\ + z 2 



Complete the specification of the transition system. Use structural induction on 
Aexp to prove that the meaning of a defined by this relation is the same as that 
defined by A. □ 
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Exercise 2.12 In a similar way we can specify a natural semantics for the boolean 
expressions. The transitions will have the form 

(b, s) ->Bexp t 

where t e T. Specify the transition system and prove that the meaning of b defined 
in this way is the same as that defined by B. □ 

Exercise 2.13 Determine whether or not semantic equivalence of Si and S 2 
amounts to 5 ns [5i] = SnsJ-Sy. D 



2.2 Structural operational semantics 

In structural operational semantics the emphasis is on the individual steps of the 
execution, that is the execution of assignments and tests. The transition relation 
has the form 

{S, s) =► 7 

where 7 either is of the form (5", s') or of the form s'. The transition expresses 
the first step of the execution of S from state s. There are two possible outcomes: 

• If 7 is of the form (5", s') then the execution of S from s is not completed and 
the remaining computation is expressed by the intermediate configuration 

(S',8'). 

• If 7 is of the form s 1 then the execution of S from s has terminated and the 
final state is s'. 

We shall say that {S : s) is stuck if there is no 7 such that (5, s) => 7. 

The definition of =>- is given by the axioms and rules of Table 2.2 and the 
general form of these are as in the previous section. Axioms [ass sos ] and [skip sos ] 
have not changed at all because the assignment and skip statements are fully 
executed in one step. 

The rules [comp^J and [comp s 2 os ] express that to execute Si,S 2 in state s we 
first execute Si one step from s. Then there are two possible outcomes: 

• If the execution of Si has not been completed we have to complete it before 
embarking on the execution of S 2 ■ 

• If the execution of Si has been completed we can start on the execution of 

s 2 . 
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(x :— a, s) =>- s[x\- >A{a}s] 



[skip sos ] 



(skip, s) =>- s 



[comp^J 



(S u s) =► (S'i, a') 



[comp s 2 os ] 



<5i;5 2 , s) (S' l] S 2 , s' 
(Si, s) => s' 



> 



<5i;5 2 , a) (S 2 , a') 



[if 11 1 

L sosJ 



(if 6 then Si else 5 2 , 5) => (S u s) if B{b}s = tt 



[if s i] 



(if 6 then Si else 5 2 , 5} (S 2 , s) if B{b]s = fF 



[while sos ] 



(while b do 5, s) =>• 

(if 6 then (S; while b do S) else skip, s) 



Table 2.2: Structural operational semantics for While 



The first case is captured by the rule [comp^J: If the result of executing the first 
step of (5, s) is an intermediate configuration (5"i, s') then the next configuration 
is {S'i,S 2 , s') showing that we have to complete the execution of Si before we can 
start on S 2 . The second case above is captured by the rule [comp s 2 os ]: If the result 
of executing Si from s is a final state s' then the next configuration is {S 2l a'), so 
that we can now start on S 2 ■ 

From the axioms [if s "J and [if^J we see that the first step in executing a 
conditional is to perform the test and to select the appropriate branch. Finally, the 
axiom [while sos ] shows that the first step in the execution of the while-construct is 
to unfold it one level, that is to rewrite it as a conditional. The test will therefore 
be performed in the second step of the execution (where one of the axioms for the 
if -construct is applied). We shall see an example of this shortly. 

A derivation sequence of a statement S starting in state a is either 

• a finite sequence 

To, 7i, 72, 7k 

of configurations satisfying 70 = {S : a), 71 =>• 7i +1 for 0<i<k, k>0, and where 
7k is either a terminal configuration or a stuck configuration, or it is 

• an infinite sequence 

7o, 7i, 72, ••• 
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of configurations satisfying 70 = {S, s) and 71 =>- 7i +1 for 0<i 

We shall write 70 7i to indicate that there are i steps in the execution from 
70 to 71 and we write 70 7i to indicate that there is a finite number of steps. 
Note that 70 7i and 70 7i need no£ be derivation sequences: they will be 
so if and only if 7^ is either a terminal configuration or a stuck configuration. 

Example 2.14 Consider the statement 

(z := x; x := y); y := z 

of Chapter 1 and let s be the state that maps all variables except x and y to 
and that has s x = 5 and s y = 7. We then have the derivation sequence: 

((z := x; x := y); y := z, a > 

(x := y; y := z, s [zH>5]) 
(y := z, (so[z^5])[xh^7]) 
=>- ((s [z^5])[x^7])[y^5] 

Corresponding to each of these steps we have derivation trees explaining why they 
take place. For the first step 

((z := x; x := y); y := z, a > => (x := y; y := z, s [zi->5]> 

the derivation tree is 

(z := x, s ) => s [z\-+5] 
(z := x; x := y, a > (x := y, s [zH>5]} 

((z := x; x := y); y := z, a > (x := y; y := z, s [z^5]) 

and it has been constructed from the axiom [ass sos ] and the rules [comp^J and 
[comp s 2 os ]. The derivation tree for the second step is constructed in a similar way 
using only [ass sos ] and [comp s 2 os ] and for the third step it simply is an instance of 
[ass sos ]. □ 

Example 2.15 Assume that s x = 3. The first step of execution from the con- 
figuration 

(y:=l; while ->(x=l) do (y:=y * x; x:=x-l), s) 
will give the configuration 

(while -i(x=l) do (y:=y * x; x:=x— l), s[yi->l]) 
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This is achieved using the axiom [ass sos ] and the rule [comp s 2 os ] as shown by the 
derivation tree: 

<y:=l, s) => s[j^l] 

(y:=l; while -i(x=l) do (y:=y*x; x:=x— l), s) =>• 
(while -i(x=l) do (y:=y*x; x:=x— l), s[yi-»l]) 

The next step of the execution will rewrite the loop as a conditional using the 
axiom [while sos ] so we get the configuration 

(if -i(x=l) then ((y:=y*x; x:=x— l); 

while -i(x=l) do (y:=y*x; x:=x— l)) 
else skip, s[yi-»l]) 

The following step will perform the test and yields (according to [if B " B ]) the con- 
figuration 

((y:=y*x; x:=x-l); while -i(x=l) do (y:=y * x; x:=x-l), a[yi->l]> 
We can then use [ass sos ], [comp s 2 os ] and [comp^J to obtain the configuration 

(x:=x— 1; while -i(x=l) do (y:=y * x; x:=x— l), s[yi->3]) 
as is verified by the derivation tree: 

(y:=y*x, a[yi->l])=>a[yi->3] 

(y:=y*x; x:=x-l, s[yi->-l])=>(x:=x-l, s[y^3]) 

((y:=y*x; x:=x-l); while ->(x=l) do (y:=y*x; x:=x-l), a[yi->l]> => 
(x:=x— 1; while -i(x=l) do (y:=y * x; x:=x— l), s[yi— >-3]) 

Using [ass sos ] and [comp s 2 os ] the next configuration will then be 

(while -i(x=l) do (y:=y * x; x:=x-l), s[yi->3][xi->2]) 
Continuing in this way we eventually reach the final state s[yi->6][xi->l]. □ 
Exercise 2.16 Construct a derivation sequence for the statement 

z:=0; while y<x do (z:=z+l; x:=x— y) 

when executed in a state where x has the value 17 and y has the value 5. Determine 
a state s such that the derivation sequence obtained for the above statement and 
s is infinite. □ 
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Given a statement S in the language While and a state s it is always possible 
to find at least one derivation sequence that starts in the configuration (5, s): 
simply apply axioms and rules forever or until a terminal or stuck configuration is 
reached. Inspection of Table 2.2 shows that there are no stuck configurations in 
While and Exercise 2.22 below will show that there is in fact only one derivation 
sequence that starts with {S : s). However, some of the constructs considered in 
Section 2.4 that extend While will have configurations that are stuck or more 
than one derivation sequence that starts in a given configuration. 

In analogy with the terminology of the previous section we shall say that the 
execution of a statement S on a state s 

• terminates if and only if there is a finite derivation sequence starting with 
{S, s), and 

• loops if and only if there is an infinite derivation sequence starting with 
(S,s). 

We shall say that the execution of S on s terminates successfully if (5, s) =>* s' 
for some state s'; in While an execution terminates successfully if and only if it 
terminates because there are no stuck configurations. Finally, we shall say that a 
statement S always terminates if it terminates on all states, and always loops if it 
loops on all states. 

Exercise 2.17 Extend While with the construct repeat S until b and spec- 
ify the structural operational semantics for it. (The semantics for the repeat- 
construct is not allowed to rely on the existence of a while-construct.) □ 

Exercise 2.18 Extend While with the construct for x := oi to a2 do S and 
specify the structural operational semantics for it. Hint: You may need to assume 
that you have an "inverse" to JV, so that there is a numeral for each number that 
may arise during the computation. (The semantics for the f or-construct is not 
allowed to rely on the existence of a while-construct.) □ 



Properties of the semantics 

For structural operational semantics it is often useful to conduct proofs by in- 
duction on the length of the derivation sequences. The proof technique may be 
summarized as follows: 



2.2 Structural operational semantics 



37 



Induction on the Length of Derivation Sequences 



1: Prove that the property holds for all derivation sequences of length 0. 

2: Prove that the property holds for all other derivation sequences: Assume 
that the property holds for all derivation sequences of length at most k 
(this is called the induction hypothesis) and show that it holds for deriva- 
tion sequences of length k+1. 



The induction step of a proof following this principle will often be done by inspect- 
ing either 

• the structure of the syntactic element, or 

• the derivation tree validating the first transition of the derivation sequence. 

Note that the proof technique is a simple application of mathematical induction. 

To illustrate the use of the proof technique we shall prove the following lemma 
(to be used in the next section). Intuitively, the lemma expresses that the execution 
of a composite construct Si]S 2 can be split into two parts, one corresponding to 
Si and the other corresponding to S 2 . 



Lemma 2.19 If {Si,S 2 , s) =^> k s" then there exists a state s' and natural numbers 
ki and k 2 such that {S 1: s) => kl s' and {S 2 , s') =^ k2 s" where k = ki+k 2 . 



Proof: The proof is by induction on the number k, that is by induction on the 
length of the derivation sequence {Si]S 2 , s) => k s". 
If k = then the result holds vacuously. 

For the induction step we assume that the lemma holds for k < k and we shall 
prove it for k +l. So assume that 

(S i; S 2 , s) ^ k ° +1 s" 

This means that the derivation sequence can be written as 

<S i; S 2 , s) => 7 ^ k0 s" 

for some configuration 7. Now one of two cases applies depending on which of the 
two rules [comp^] and [comp s 2 os ] was used to obtain {Si]S 2 , s) =>• 7. 
In the first case where [compjJ,J is used we have 

(S i; S 2 , s) <S' i; S 2 , a') 



because 
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(S u s) =► (S[, s>) 
We therefore have 

(S' i; S 2 , s') a" 

and the induction hypothesis can be applied to this derivation sequence because 
it is shorter than the one we started with. This means that there is a state s and 
natural numbers ki and k 2 such that 

(S[, s') s and (S 2 , s ) ^ s" 

where ki+k 2 =k . Using that (Si, s) => (S[, s') and (S[, 5'} =^ kl s we get 

a) ^ kl+1 s 

We have already seen that (S 2 , s ) =^ k2 s" and since (ki+l)+k 2 = k +l we have 
proved the required result. 

The second possibility is that [comp s 2 os ] has been used to obtain the derivation 
(Si,S 2 , s) => 7. Then we have 

(Si, s) => s' 

and 7 is (S 2 , s') so that 

(S 2 , s') => k ° s" 

The result now follows by choosing ki=l and k 2 =k . □ 

Exercise 2.20 Suppose that (Si,S 2 , s)^*(S 2 , s'). Show that it is not necessarily 
the case that (Si, s)=>V. □ 

Exercise 2.21 (Essential) Prove that 

if (Si, s) ^ k s' then (Si,S 2 , a) =^ k (S 2 , s') 
that is the execution of Si is not influenced by the statement following it. □ 

In the previous section we defined a notion of determinism based on the natural 
semantics. For the structural operational semantics we define the similar notion 
as follows. The semantics of Table 2.2 is deterministic if for all choices of S, s, 7 
and 7' we have that 

(S, s) =>- 7 and (S, s) =>- 7' imply 7 = 7' 
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Exercise 2.22 (Essential) Show that the structural operational semantics of 
Table 2.2 is deterministic. Deduce that there is exactly one derivation sequence 
starting in a configuration (5, s). Argue that a statement S of While cannot both 
terminate and loop on a state s and hence it cannot both be always terminating 
and always looping. □ 

In the previous section we defined a notion of two statements Si and S2 being 
semantically equivalent. The similar notion can be defined based on the structural 
operational semantics: Si and S2 are semantically equivalent if for all states s 

• {Si : s) =>* 7 if and only if {S 2l s) =>* 7, whenever 7 is a configuration that 
is either stuck or terminal, and 

• there is an infinite derivation sequence starting in (£1, s) if and only if there 
is one starting in {S 2l s). 

Note that in the first case the length of the two derivation sequences may be 
different. 

Exercise 2.23 Show that the following statements of While are semantically 
equivalent in the above sense: 

• tS^skip and S 

• while b do S and if b then (S; while b do S) else skip 

• Si;(S 2 ]S 3 ) and (Si]S 2 );S 3 

You may use the result of Exercise 2.22. Discuss to what extent the notion of 
semantic equivalence introduced above is the same as that defined from the natural 
semantics. □ 

Exercise 2.24 Prove that repeat S until b (as defined in Exercise 2.17) is se- 
mantically equivalent to S] while -1 b do S. □ 

The semantic function <S S0S 

As in the previous section the meaning of statements can be summarized by a 
(partial) function from State to State: 

<S S0S : Stm — >■ (State c -» State) 

It is given by 

' s' if (S, s) ^* s' 
undef otherwise 



The well-definedness of the definition follows from Exercise 2.22. 

Exercise 2.25 Determine whether or not semantic equivalence of Si and S 2 
amounts to S^lSi] = Ssosl-S^]- D 
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2.3 An equivalence result 

We have given two definitions of the semantics of While and we shall now address 
the question of their equivalence. 



Theorem 2.26 For every statement S of While we have <5 ns [[>5l = <5 S0S [5']. 



This result expresses two properties: 

• If the execution of S from some state terminates in one of the semantics then 
it also terminates in the other and the resulting states will be equal. 

• If the execution of S from some state loops in one of the semantics then it 
will also loop in the other. 

It should be fairly obvious that the first property follows from the theorem because 
there are no stuck configurations in the structural operational semantics of While. 
For the other property suppose that the execution of S on state s loops in one 
of the semantics. If it terminates in the other semantics we have a contradiction 
with the first property because both semantics are deterministic (Theorem 2.9 and 
Exercise 2.22). Hence S will have to loop on state s also in the other semantics. 

The theorem is proved in two stages as expressed by Lemma 2.27 and Lemma 
2.28 below. We shall first prove: 



Lemma 2.27 For every statement S of While and states s and s' we have 

(S, s) s' implies (S, s) s'. 

So if the execution of S from s terminates in the natural semantics then it will 
terminate in the same state in the structural operational semantics. 



Proof: The proof proceeds by induction on the shape of the derivation tree for 
(S, s) > s'. 

The case [ass ns ]: We assume that 

{x := a, s) — > s[x^-Ala}s] 
From [ass sos ] we get the required 

{x := a, s) =3- s[x^-A[a}s] 

The case [skip ns ]: Analogous. 
The case [comp ns ]: Assume that 



2.3 An equivalence result 



41 



(5 i; 5 2 , a) -> 5 " 
because 

(S u a) -> 5' and (5 2 , a') -> 5" 

The induction hypothesis can be applied to both of the premises (5i, a) — > s' and 
(52, a') — >■ a" and gives 

(5i, a) a' and (5 2 , a') a" 

From Exercise 2.21 we get 

(5 i; 5 2 , a) ^* (5 2 , a') 

and thereby (5i;5 2 , a) =>* a". 
The case [if**]: Assume that 

(if 6 then S\ else 5 2 , a) — > s' 

because 

= tt and (S 1: a) -> a' 

Since jEJ[6]s = tt we get 

(if b then 5i else 5 2 , a) (5i, a) a' 

where the first relationship comes from [if** s ] and the second from the induction 
hypothesis applied to the premise (5i, a) — > a'. 

The case [if^]: Analogous. 

The case [while**]: Assume that 

(while b do 5, a) -> a" 

because 

= tt, (5, a) -> a' and (while 6 do 5, a') -> a" 

The induction hypothesis can be applied to both of the premises (5, a) — > a' and 
(while b do 5, a') — >■ a" and gives 

(5, a) a' and (while b do 5, a') a" 
Using Exercise 2.21 we get 

(5; while 6 do 5, a) a" 
Using [while sos ] and [if**J (with B{b}s = tt) we get the first two steps of 
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(while b do S, s) 

=>- (if b then (S; while b do S) else skip, s) 
=> (5; while 6 do S, s) 

^* a" 

and we have already argued for the last part. 

The case [while^J: Straightforward. □ 

This completes the proof of Lemma 2.27. The second part of the theorem 
follows from: 



Lemma 2.28 For every statement S of While, states s and s' and natural number 
k we have that 

(S, s) =^ k s' implies (S, s) -» s'. 

So if the execution of S from s terminates in the structural operational semantics 
then it will terminate in the same state in the natural semantics. 



Proof: The proof proceeds by induction on the length of the derivation sequence 
(5, s) =^ k s', that is by induction on k. 
If k=0 then the result holds vacuously. 

To prove the induction step we assume that the lemma holds for k < k and 
we shall then prove that it holds for k +l. We proceed by cases on how the first 
step of (5, 5) => k ° +1 s' is obtained, that is by inspecting the derivation tree for 
the first step of computation in the structural operational semantics. 

The case [ass sos ]: Straightforward (and k = 0). 

The case [skip sos ]: Straightforward (and k = 0). 

The cases [comp^J and [comp s 2 os ]: In both cases we assume that 

(S i; S 2 , s) ^ k ° +1 s" 

We can now apply Lemma 2.19 and get that there exists a state s' and natural 
numbers k x and k 2 such that 

(S 1: s) s' and (S 2 , s') ^ k2 s" 

where ki+k 2 =k +l. The induction hypothesis can now be applied to each of these 
derivation sequences because ki < k and k 2 < k . So we get 

(Si, s) -> s' and (S 2 , s') -> s" 
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Using [comp ns ] we now get the required (Si]S 2 , s) — > s". 
The case [if s "J: Assume that B{b}s = tt and that 

(if b then Si else S 2 , s) => (Si, s) =^ k ° s' 

The induction hypothesis can be applied to the derivation sequence (Si, s) =^ k ° s' 
and gives 

(Si, s) -> s' 

The result now follows using [if**]. 
The case [if S oJ: Analogous. 
The case [while sos ]: We have 

(while b do S, s) 

=>- (if b then (S; while b do S) else skip, s) 

=> k ° s" 

The induction hypothesis can be applied to the k last steps of the derivation 
sequence and gives 

(if b then (S; while b do S) else skip, s) — > s" 

and from Lemma 2.5 we get the required 

(while b do S, s) -> s" □ 

Proof of Theorem 2.26: For an arbitrary statement S and state s it follows 
from Lemmas 2.27 and 2.28 that if <5 ns [»S']5 = s' then tSgosJ^Js = s' and vice versa. 
This suffices for showing that the functions tSnsI'S'] and tSsoslS'] must be equal: if 
one is defined on a state s then so is the other, and therefore, if one is not defined 
on a state s then neither is the other. □ 

Exercise 2.29 Consider the extension of the language While with the statement 
repeat S until b. The natural semantics of the construct was considered in 
Exercise 2.7 and the structural operational semantics in Exercise 2.17. Modify the 
proof of Theorem 2.26 so that the theorem applies to the extended language. □ 

Exercise 2.30 Consider the extension of the language While with the statement 
for x := oi to a 2 do S. The natural semantics of the construct was considered in 
Exercise 2.8 and the structural operational semantics in Exercise 2.18. Modify the 
proof of Theorem 2.26 so that the theorem applies to the extended language. □ 
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The proof technique employed in the proof of Theorem 2.26 may be summa- 
rized as follows: 



Proof Summary for While: 
Equivalence of two Operational Semantics 



1: Prove by induction on the shape of derivation trees that for each derivation 
tree in the natural semantics there is a corresponding finite derivation 
sequence in the structural operational semantics. 

2: Prove by induction on the length of derivation sequences that for each 
finite derivation sequence in the structural operational semantics there is 
a corresponding derivation tree in the natural semantics. 



When proving the equivalence of two operational semantics for a language with 
additional programming constructs one may need to amend the above proof tech- 
nique. One reason is that the equivalence result may have to be expressed dif- 
ferently from that of Theorem 2.26 (as will be the case if the extended language 
is non-deterministic). Also one might want to consider only some of the finite 
derivation sequences, for example those ending in a terminal configuration. 

2.4 Extensions of While 

In order to illustrate the power and weakness of the two approaches to operational 
semantics we shall consider various extensions of the language While. For each 
extension we shall show how to modify the operational semantics. 

Abortion 

We first extend While with the simple statement abort. The idea is that abort 
stops the execution of the complete program. This means that abort behaves 
differently from while true do skip in that it causes the execution to stop rather 
than loop. Also abort behaves differently from skip because a statement following 
abort will never be executed whereas one following skip certainly will. 
Formally, the new syntax of statements is given by: 

S ::= x := a | skip Si ; S2 | if b then Si else S2 

while b do S | abort 

We shall not repeat the definitions of the sets of configurations but tacitly assume 
that they are modified so as to correspond to the extended syntax. The task that 
remains, therefore, is to define the new transition relations — > and =>. 
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The fact that abort stops the execution of the program is modelled by ensuring 
that the configurations of the form (abort, s) are stuck. Therefore the natural 
semantics of the extended language is still defined by the transition relation — > 
of Table 2.1. So although the language and thereby the set of configurations have 
been extended we do not modify the definition of the transition relation. Similarly, 
the structural operational semantics of the extended language is still defined by 
Table 2.2. 

From the structural operational semantics point of view it is clear now that 
abort and skip cannot be semantically equivalent. This is because 

(skip, s) ^ s 

is the only derivation sequence for skip starting in s and 
(abort, s) 

is the only derivation sequence for abort starting in s. Similarly, abort cannot be 
semantically equivalent to while true do skip because 

(while true do skip, s) 

=>- (if true then (skip; while true do skip) else skip, s) 

=>- (skip; while true do skip, s) 

(while true do skip, s) 

=^ • • • 

is an infinite derivation sequence for while true do skip whereas abort has none. 
Thus we shall claim that the structural operational semantics captures the informal 
explanation given earlier. 

From the natural semantics point of view it is also clear that skip and abort 
cannot be semantically equivalent. However, it turns out that while true do skip 
and abort are semantically equivalent! The reason is that in the natural semantics 
we are only concerned with executions that terminate properly. So if we do not 
have a derivation tree for (5, s) — > s' then we cannot tell whether it is because we 
entered a stuck configuration or a looping execution. We can summarize this as 
follows: 



Natural Semantics versus Structural Operational Semantics 



• In a natural semantics we cannot distinguish between looping and abnormal 
termination. 

• In a structural operational semantics looping is reflected by infinite deriva- 
tion sequences and abnormal termination by finite derivation sequences end- 
ing in a stuck configuration. 
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We should note, however, that if abnormal termination is modelled by "normal 
termination" in a special error configuration (included in the set of terminal config- 
urations) then we can distinguish between the three statements in both semantic 
styles. 

Exercise 2.31 Theorem 2.26 expresses that the natural semantics and the struc- 
tural operational semantics of While are equivalent. Discuss whether or not a 
similar result holds for While extended with abort. □ 

Exercise 2.32 Extend While with the statement 
assert b before S 

The idea is that if b evaluates to true then we execute S and otherwise the execution 
of the complete program aborts. Extend the structural operational semantics 
of Table 2.2 to express this (without assuming that While contains the abort- 
statement). Show that assert true before S is semantically equivalent to S but 
that assert false before S neither is equivalent to while true do skip nor 
skip. □ 



Non-determinism 

The second extension of While has statements given by 

S ::= x :— a skip S± ; S 2 \ if b then Si else £2 
while b do S \ Si or S 2 

The idea is here that in £1 or S 2 we can non-deterministically choose to execute 
either £1 or S 2 . So we shall expect that execution of the statement 

x := 1 or (x := 2; x := x + 2) 

could result in a state where x has the value 1, but it could as well result in a state 
where x has the value 4. 

When specifying the natural semantics we extend Table 2.1 with the two rules: 

[° r nsJ 

{Si or £2, s) ->■ s' 

r 21 <S 2 , *)->*' 
[° r nsJ 

{Si or S 2 , s) -> s' 

Corresponding to the configuration (x := 1 or (x := 2; x := x+2), s) we have 
derivation trees for 

(x := 1 or (x := 2; x := x+2), s) ->■ s[xi->l] 
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as well as 

(x := 1 or (x := 2; x := x+2), s) ->■ s[xi->4] 

It is important to note that if we replace x := 1 by while true do skip in the 
above statement then we will only have one derivation tree, namely that for 

((while true do skip) or (x := 2; x := x+2), s) — > s[xi->4] 

Turning to the structural operational semantics we shall extend Table 2.2 with 
the two axioms: 

[° r S o S ] (Si or S 2 , s) => (Si, s) 

KJ {S 1 or S 2 , s) =► {S 2 , s) 

For the statement x:=lor(x:=2;x:= x+2) we have two derivation sequences: 

(x := 1 or (x := 2; x := x+2), s) =>* a[»-»l] 

and 

(x := 1 or (x := 2; x := x+2), s) =>* s[xH>4] 

If we replace x := 1 by while true do skip in the above statement then we still 
have two derivation sequences. One is infinite 

((while true do skip) or (x := 2; x := x+2), s) 
=>- (while true do skip, s) 
=> 3 (while true do skip, s) 

=> 

and the other is finite 

((while true do skip) or (x := 2; x := x+2), s) =>* s[xi->4] 

Comparing the natural semantics and the structural operational semantics we 
see that the latter can choose the "wrong" branch of the or-statement whereas 
the first always chooses the "right" branch. This is summarized as follows: 

Natural Semantics versus Structural Operational Semantics 

• In a natural semantics non- determinism will suppress looping, if possible. 

• In a structural operational semantics non- determinism does not suppress 
looping. 
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Exercise 2.33 Consider the statement 

x := —1; while x<0 do (x := x— 1 or x := (— l)*x) 

Given a state s describe the set of final states that may result according to the 
natural semantics. Further describe the set of derivation sequences that are spec- 
ified by the structural operational semantics. Based on this discuss whether or 
not you would regard the natural semantics as being equivalent to the structural 
operational semantics for this particular statement. □ 

Exercise 2.34 We shall now extend While with the statement 
random(x) 

and the idea is that its execution will change the value of x to be any positive 
natural number. Extend the natural semantics as well as the structural operational 
semantics to express this. Discuss whether random(a;) is a superfluous construct 
in the case where While is also extended with the or construct. □ 



Parallelism 

We shall now consider an extension of While with a parallel construct. So now 
the syntax of expressions is given by 

S ::= x :— a \ skip \ Si ; S 2 | if b then Si else S 2 
while b do S \ S\ par 

The idea is that both statements of Si par S 2 have to be executed but that the 
execution can be interleaved. This means that a statement like 

x := 1 par (x := 2; x := x+2) 

can give three different results for x, namely 4, 1 and 3: If we first execute x := 1 
and then x := 2; x := x+2 we get the final value 4. Alternatively, if we first 
execute x := 2; x := x+2 and then x := 1 we get the final value 1. Finally, we 
have the possibility of first executing x := 2, then x := 1 and lastly x := x+2 and 
we then get the final value 3. 

To express this in the structural operational semantics we extend Table 2.2 
with the following rules: 

r 1 , (Si, s) =► <si, a '> 

[P ar sos] 



[par s 2 0S ] 



{Si par S 2 , s) => (S[ par S 2 , s') 

(Si, s) => s' 
(£1 par S 2 , s) =^ {S 2 , s') 
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[par s 3 0S ] 



(S 2 , s) =► (S' 2 , s') 



[P ar s 4 os] 



(Si par 52, s) (Si par S 2 , s') 

(S 2 , s) a' 



(Si par S 2 , s) (Si, s') 



The first two rules take account of the case where we begin by executing the first 
step of statement Si. If the execution of Si is not fully completed we modify the 
configuration so as to remember how far we have reached. Otherwise only S 2 has 
to be executed and we update the configuration accordingly. The last two rules 
are similar but for the case where we begin by executing the first step of S 2 . 

Using these rules we get the following derivation sequences for the example 
statement: 

(x := 1 par (x := 2; x := x+2), s) =4> (x := 2; x := x+2, a[»->l]> 

=> (x := x+2, s[xH>2]} 
=> s[xi->4] 

(x := 1 par (x := 2; x := x+2), s) => (x := 1 par x := x+2, s[xi->2]) 

=> (x := 1, s[xH>4]) 
=> s[xt->l] 



(x := 1 par (x := 2; x := x+2), s) => (x := 1 par x := x+2, s[xi->2]) 

=^ (x := x+2, s[xi->l]) 
^> s[xi-^3] 

Turning to the natural semantics we might start by extending Table 2.1 with 
the two rules: 



However, it is easy to see that this will not do because the rules only express 
that either Si is executed before S 2 or vice versa. This means that we have lost 
the ability to interleave the execution of two statements. Furthermore, it seems 
impossible to be able to express this in the natural semantics because we consider 
the execution of a statement as an atomic entity that cannot be split into smaller 



and 



(Si, s) -> s', (S 2 , s') -> s 
(Si par S 2 , s) — > s" 



it 



(S 2 , s) -> s', (Si, s') -> s 
(Si par S 2 , s) ->■ s" 



n 
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pieces. This may be summarized as follows: 



Natural Semantics versus Structural Operational Semantics 



• In a natural semantics the execution of the immediate constituents is an 
atomic entity so we cannot express interleaving of computations. 

• In a structural operational semantics we concentrate on the small steps of 
the computation so we can easily express interleaving. 



Exercise 2.35 Consider an extension of While that in addition to the par- 
construct also contains the construct 

protect S end 

The idea is that the statement S has to be executed as an atomic entity so that 
for example 

x := 1 par protect (x := 2; x := x+2) end 

only has two possible outcomes namely 1 and 4. Extend the structural operational 
semantics to express this. Can you specify a natural semantics for the extended 
language? □ 

Exercise 2.36 Specify a structural operational semantics for arithmetic expres- 
sions where the individual parts of an expression may be computed in parallel. 
Try to prove that you still obtain the result that was specified by A. □ 

2.5 Blocks and procedures 

We now extend the language While with blocks containing declarations of vari- 
ables and procedures. In doing so we introduce a couple of important concepts: 

• variable and procedure environments, and 

• locations and stores. 

We shall concentrate on the natural semantics and will consider dynamic as well 
as static scope and non-recursive as well as recursive procedures. 
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Blocks and simple declarations 

We first extend the language While with blocks containing declarations of local 
variables. The new language is called Block and its syntax is 

S ::= x := a \ skip | Si ; S2 | if b then Si else S2 
while b do S | begin Dy S end 

where D v is a meta- variable ranging over the syntactic category Dec v of variable 
declarations. The syntax of variable declarations is given by: 

D v '■'■= var x := a; D v | £ 

where e is the empty declaration. The idea is that the variables declared inside a 
block begin Dy S end are local to it. So in a statement like 

begin var y := 1; 

(x := 1; 

begin var x := 2; y := x+1 end; 
x := y+x) 

end 

the x in y := x+1 relates to the local variable x introduced by var x := 2, whereas 
the x in x := y+x relates to the global variable x that is also used in the statement 
x := 1. In both cases the y refers to the y declared in the outer block. Therefore, 
the statement y := x+1 assigns y the value 3, rather than 2, and the statement 
x := y+x assigns x the value 4, rather than 5. 

Before going into the details of how to specify the semantics we shall define the 
set DV(ZV) of variables declared in D v : 

DV(var x := a; D v ) = {x} U DV(D V ) 

DV(e) = 

We next define the natural semantics. The idea will be to have one transi- 
tion system for each of the syntactic categories Stm and Dec v . For statements 
the transition system is as in Table 2.1 but extended with the rule of Table 2.3. 
The transition system for variable declarations has configurations of the two forms 
(Z?y, s) and s and the idea is that the transition relation — > D specifies the rela- 
tionship between initial and final states as before: 

(D v , s) s' 

The relation — > D for variable declarations is given in Table 2.4. We generalize the 
substitution operation on states and write s'[X\ — >s] for the state that is as s' 
except for variables in the set X where it is as specified by s. Formally, 
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<£> y , s) ^ D s', (S, s') -> s" 

[block ns J 



(begin D v S end, s) s"[DV(D v )i — 



Table 2.3: Natural semantics for statements of Block 



(D v , s[x^A[a]s]) s' 

[var ns J 



(var x := a; Dy, s) —>£> s' 
[none ns ] (e, s) -+ D s 



Table 2.4: Natural semantics for variable declarations 

(«'[*-►«])* = { V 

This operation will ensure that local variables are restored to their previous values 
when the block is left. 

Exercise 2.37 Use the natural semantics of Table 2.3 to show that execution of 
the statement 

begin var y := 1; 

(x := 1; 

begin var x := 2; y := x+1 end; 
x := y+x) 

end 

will lead to a state where x has the value 4. □ 

It is somewhat harder to specify a structural operational semantics for the ex- 
tended language. One approach is to replace states with a structure that is similar 
to the run-time stacks used in the implementation of block structured languages. 
Another is to extend the statements with fragments of the state. However, we 
shall not go further into this. 



Procedures 

We shall now extend the language Block with procedure declarations. The syntax 
of the language Proc is: 

S ::= x := a | skip | Si ; S2 | if b then Si else S2 

while b do S begin D v D P S end | call p 

D v '■'■= var x := a; D v | £ 

Dp ::= proc p is 5; D P | e 
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Here p is a meta- variable ranging over the syntactic category Pname of procedure 
names; in the concrete syntax there need not be any difference between procedure 
names and variable names but in the abstract syntax it is convenient to be able 
to distinguish between the two. Furthermore, D P is a meta- variable ranging over 
the syntactic category Dec P of procedure declarations. 

We shall give three different semantics of this language. They differ in their 
choice of scope rules for variables and procedures: 

• dynamic scope for variables as well as procedures, 

• dynamic scope for variables but static scope for procedures, and 

• static scope for variables as well as procedures. 

To illustrate the difference consider the statement 

begin var x := 0; 

proc p is x := x * 2; 
proc q is call p; 
begin var x := 5; 

proc p is x := x + 1; 
call q; y := x 

end 

end 

If dynamic scope is used for variables as well as procedures then the final value 
of y is 6. The reason is that call q will call the local procedure p which will 
update the local variable x. If we use dynamic scope for variables but static scope 
for procedures then y gets the value 10. The reason is that now call q will call 
the global procedure p and it will update the local variable x. Finally, if we use 
static scope for variables as well as procedures then y gets the value 5. The reason 
is that call q now will call the global procedure p which will update the global 
variable x so the local variable x is unchanged. 

Dynamic scope rules for variables and procedures 

The general idea is that to execute the statement call p we shall execute the 
body of the procedure. This means that we have to keep track of the association 
of procedure names with procedure bodies. To facilitate this we shall introduce 
the notion of a procedure environment. Given a procedure name the procedure 
environment env P will return the statement that is its body. So env P is an element 
of 
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[ass ns ] 


envp h (x := a, s) — > s[x^Alajs] 


[skip ns ] 


envp h (skip, s) — > s 


[comp ns ] 


envp h (Si, s) — > s', envp h (S2, s') —> s" 
envp h (SuSo, s) — >■ 5" 




envp h (iSi, 5) — >■ 5' 
enwp h (if 6 then 5i else ^2, 5} — » s' 
if B[b]s = tt 




enwp h (52, 5) — >■ s' 
envp h (if 6 then Si else £2, 5} — > s' 
if B[b]s = ff 


[while*] 


envp h (5, 5) — > s', envp h (while b do 5, 5') — > s" 
envp h (while 6 do 5, 5) — > s" 
if B[b}s = tt 


[while*] 


envp h (while 6 do S, s) — > s 
if B[b}s = ff 


[block ns ] 


m s \ s > UD dpfDp envp) h (5 s'^ — >■ s" 


enwp h (begin £> y £> P 5 end, 5) ->• s"[DV(D v )i — ►a] 


[call-] 


enwp h (5, 5) — >■ 5' 

where envp p = S 

envp h (call p, 5) — > s' 



Table 2.5: Natural semantics for Proc with dynamic scope rules 



Envp = Pname Stm 

The next step will be to extend the natural semantics to take the environ- 
ment into account. We shall extend the transition system for statements to have 
transitions of the form 

envp h (S, s) — > s' 

The presence of the environment means that we can always access it and therefore 
get hold of the bodies of declared procedures. The result of modifying Table 2.1 
to incorporate this extra information is shown in Table 2.5. 
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Concerning the rule for begin D v D P S end the idea is that we update the 
procedure environment so that the procedures declared in D P will be available 
when executing S. Given a global environment env P and a declaration D P , the 
updated procedure environment, updp(.Dp, env P ), is specified by: 

updp(proc p is S; D P , env P ) = updp(Dp, env P [p\- >S\) 
updp(e, env P ) = env P 

As the variable declarations do not need to access the procedure environment 
it is not necessary to extend the transition system for declarations with the extra 
component. So for variable declarations we still have transitions of the form 

(D, s) -+ D s' 

The relation is defined as for the language Block, that is by Table 2.4. 

We can now complete the specification of the semantics of blocks and procedure 
calls. Note that in the rule [block ns ] of Table 2.5 we use the updated environment 
when executing the body of the block. In the rule [calln S c ] for procedure calls 
we make use of the information provided by the environment. It follows that 
procedures will always be recursive. 

Exercise 2.38 Consider the following statement of Proc: 

begin proc f ac is begin var z := x; 

if x = 1 then skip 

else (x := x— 1; call fac; y := z*y) 

end; 

(y := 1; call fac) 

end 

Construct a derivation tree for the execution of this statement from a state s where 
s x = 3. □ 

Exercise 2.39 Use the semantics to verify that the statement 

begin var x := 0; 

proc p is x := x * 2; 
proc q is call p; 
begin var x := 5; 

proc p is x := x + 1; 
call q; y := x 
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[call ns ] 


env' P h {S, s) — > s' 
envp h (call p, s) — > s' 

where envp p = (S , env'p) 




[call-] 


env' P [p>-^-(S, env' P )] h {S, s) — > s' 
envp h (call p, s) — > s' 
where envp p = (S, env'p) 




Table 2.6: Procedure calls in case of mixed scope rules (choose one) 




end 






end 






considered earlier does indeed 


assign the expected value to y. 


□ 



Static scope rules for procedures 

We shall now modify the semantics of Proc to specify static scope rules for pro- 
cedures. The first step will be to extend the procedure environment env P so that 
procedure names are associated with their body as well as the procedure environ- 
ment at the point of declaration. To this end we define 

Envp = Pname ^ Stm x Env P 

This definition may seem problematic because Env P is defined in terms of itself. 
However, this is not really a problem because a concrete procedure environment 
always will be built from smaller environments starting with the empty procedure 
environment. The function updp updating the procedure environment can then 
be redefined as: 

updp(proc p is S; D P , envp) = updp(.Dp, envp[p\- >(S, envp)]) 
updp(e, envp) = envp 

The semantics of variable declarations are unaffected and so is the semantics of 
most of the statements. Compared with Table 2.5 we shall only need to modify the 
rules for procedure calls. In the case where the procedures of Proc are assumed 
to be non-recursive we simply consult the procedure environment to determine 
the body of the procedure and the environment at the point of declaration. This 
is expressed by the rule [call ns ] of Table 2.6. In the case where the procedures of 
Proc are assumed to be recursive we have to make sure that occurrences of call p 
inside the body of p refer to the procedure itself. We shall therefore update the 
procedure environment to contain that information. This is expressed by the rule 
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[call™ ] of Table 2.6. The remaining axioms and rules are as in Tables 2.5 (without 
[call™ ]) and 2.4. (Clearly a choice should be made between [call ns ] or [call™ ].) 

Exercise 2.40 Construct a statement that illustrates the difference between the 
two rules for procedure call given in Table 2.6. Validate your claim by constructing 
derivation trees for the executions of the statement from a suitable state. □ 

Exercise 2.41 Use the semantics to verify that the statement of Exercise 2.39 
assigns the expected value to y. □ 

Static scope rules for variables 

We shall now modify the semantics of Proc to specify static scope rules for vari- 
ables as well as procedures. To achieve this we shall replace the states with two 
mappings: a variable environment that associates a location with each variable and 
a store that associates a value with each location. Formally, we define a variable 
environment envy as an element of 

Env v = Var — >■ Loc 

where Loc is a set of locations. For the sake of simplicity we shall take Loc = Z. 
A store sto is an element of 

Store = Loc U { next } — > Z 

where 'next' is a special token used to hold the next free location. We shall need 
a function 

new: Loc — >■ Loc 

that given a location will produce the next one. In our case where Loc is Z we 
take 'new' to be the successor function on the integers. 

So rather than having a single mapping s from variables to values we have 
split it into two mappings envy and sto and the idea is that s = sto o envy. To 
determine the value of a variable x we shall first 

• determine the location / = envy x associated with x and then 

• determine the value sto I associated with the location /. 
Similarly, to assign a value v to a variable x we shall first 

• determine the location / = envy x associated with x and then 

• update the store to have sto I = v. 
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[var ns ] 



{D v , envv[x^l], sto[l\- >-w][nexti— >-new /]) —>£> (env' v , sto') 



(var x := a; D v , envy, sto) — >d (env' v , sto') 
where v — A[aJ(stooenvv) and / = sto next 



[none ns ] 



{e, envy, sto) —>£> (envy, sto) 



Table 2.7: Natural semantics for variable declarations using locations 

The initial variable environment could for example map all variables to the 
location and the initial store could for example map 'next' to 1. The variable 
environment (and the store) is updated by the variable declarations. The transition 
system for variable declarations is therefore modified to have the form 

{D v , envy, sto) — >d (env' v , sto') 

because a variable declaration will modify the variable environment as well as the 
store. The relation is defined in Table 2.7. Note that we use 'sto next' to determine 
the location / to be associated with x in the variable environment. Also the store 
is updated to hold the correct value for / as well as 'next'. Finally note that the 
declared variables will get positive locations. 

To obtain static scoping for variables we shall extend the procedure environ- 
ment to hold the variable environment at the point of declaration. Therefore env P 
will now be an element of 

Envp = Pname <^-> Stm x Env v x Env P 

The procedure environment is updated by the procedure declarations as before, 
the only difference being that the current variable environment is supplied as an 
additional parameter. The function upd P is now defined by: 

updp(proc p is S; D P , envy, envp) = 

updp(.Dp, envy, envp\p*-^(S , envy, envp)]) 
updp(£, envy, envp) = envp 

Finally, the transition system for statements will have the form: 

envy, envp h {S, sto) — > sto' 

so given a variable environment and a procedure environment we get a relationship 
between an initial store and a final store. The modification of Tables 2.5 and 2.6 
is rather straightforward and is given in Table 2.8. Note that in the new rule for 
blocks there is no analogue of s"[iyV(Dy)\ — >s] as the values of variables only can 
be obtained by accessing the environment. 
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[ass ns ] 


envy, envp h (x := a, sto) — > sto[l\— >v] 

wneie i — eiiuy x aiiu w — ,/i|[u]|^st0oe/i<;y,i 


[skip ns ] 


enwy, envp h (skip, sto) — > sto 


1 COTHDt.c 1 


envy, envp h (Si, sto) — >■ sto', envy, envp h (152, sto'} — >■ sto" 


enwy, enwp h (S^S^, sto) — >■ sto" 




enwy, enwp h (^i, sto) — >■ sto' 


em>y, enwp h (if 6 then Si else £2, sto) —> sto' 
if ^[6](stooenwy) = tt 


P£] 


envy, envp h (S2, sto) — > sto' 
envy, envp h (if b then Si else S2, sto) — > sto' 
if B[b\(stooenv v ) = ff 


[while*] 


envy, envp h (5, sto) — >■ sto', 
enwy, enwp h (while b do 5, sto') —> sto" 

envy, envp h (while 6 do 5, sto) — > sto" 
if ^[6](stooenwy) = tt 


[while*] 


envy, envp h (while b do 5, sto) — > sto 
if ^[6](stooenwy) = ff 


[block ns ] 


(D v , envy, sto) — >d (env' v , sto'), 
env' v , env'p h (S, sto') — > sto" 

envy, envp h (begin D v Dp S end, sto) — > sto" 
where env' P = updp (D P , env' v , envp) 


[call ns ] 


env'y, env' P h (S, sto) — > sto' 
envy, envp h (call p, sto) —¥ sto' 
where envp p = (S, env' v , env'p) 


[call-] 


env' v , env' P [p\-^(S , env' v , env'p)] h (S, sto) — > sto' 


envy, envp h (call p, sto) — > sto' 
where envp p = (S, env' v , env'p) 



Table 2.8: Natural semantics for Proc with static scope rules 
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Exercise 2.42 Apply the natural semantics of Table 2.8 to the factorial statement 
of Exercise 2.38 and a store where the location for x has the value 3. □ 

Exercise 2.43 Verify that the semantics applied to the statement of Exercise 2.39 
gives the expected result. □ 

Exercise 2.44 * An alternative semantics of the language While is defined by 
the axioms and rules [ass ns ], [skip ns ], [comp ns ], [if^], [ifjfj, [while" s ] and [whilefj of 
Table 2.8. Formulate and prove the equivalence between this semantics and that 
of Table 2.1. □ 

Exercise 2.45 Modify the syntax of procedure declarations so that procedures 
take two call-by-value parameters: 

Dp ::= proc p(xi,X2) is S; D P | e 

S ::= • • • | call p(ai,a2) 

Procedure environments will now be elements of 

Envp = Pname <^-> Var x Var x Stm x Env v x Env P 

Modify the semantics given above to handle this language. In particular, provide 
new rules for procedure calls: one for non-recursive procedures and another for 
recursive procedures. Construct statements that illustrate how the new rules are 
used. □ 

Exercise 2.46 Now consider the language Proc and the task of achieving mutual 
recursion. The procedure environment is now defined to be an element of 

Envp = Pname <^-> Stm x Env v x Env P x Dec P 

The idea is that if env P p = (S, env' v , env' P , Dp) then Dp contains all the 
procedure declarations that are made in the same block as p. Define updp by 

upd' P (proc p is S; D P , envy, env P , Dp) = 

upd' P (D P , envy, env P \p*-^(S , envy, env P ,Dp)], Dp) 

upd' P (e, envy, env P ,Dp) = env P 

Next redefine updp by 

updp(Dp, envy, env P ) = upd'p(Dp, envy, env P , D P ) 

Modify the semantics of Proc so as to obtain mutual recursion among procedures 
defined in the same block. Illustrate how the new rules are used on an interesting 
statement of your choice. 

(Hint: Convince yourself, that [calln S c ] is the only rule that needs to be changed; 
then consider whether or not the function updp might be useful in the new defi- 
nition of [call^].) □ 
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Exercise 2.47 We shall consider a variant of the semantics where we use the 
variable environment rather than the store to hold the next free location. So 
assume that 

Env v = Var U { next } — > Loc 

and 

Store = Loc — > Z 

As before we shall write sto o env v for the state obtained by first using env v to 
find the location of the variable and then sto to find the value of the location. The 
clauses of Table 2.7 are now replaced by 

(D v , envy [zi— >-/][nexti— >-new I], sto[lt->v]) — »£> (env' v , sto') 
(var x := a; D v , envy, sto) —>£> (env' v , sto') 
where v = A\a\(stooenvv) and / = envy next 

(e, envy, sto) — >d (envy, sto) 

Construct a statement that computes different results under the two variants of the 
semantics. Validate your claim by constructing derivation trees for the executions 
of the statement from a suitable state. □ 
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Chapter 3 

Provably Correct Implementation 



A formal specification of the semantics of a programming language is useful when 
implementing it. In particular, it becomes possible to argue about the correctness 
of the implementation. We shall illustrate this by showing how to translate the 
language While into a structured form of assembler code for an abstract machine 
and we shall then prove that the translation is correct. The idea is that we first de- 
fine the meaning of the abstract machine instructions by an operational semantics. 
Then we define translation functions that will map expressions and statements in 
the While language into sequences of such instructions. The correctness result 
will then state that if we 

• translate a program into code, and 

• execute the code on the abstract machine, 

then we get the same result as was specified by the semantic functions S ns and 
tS S0S of the previous chapter. 

3.1 The abstract machine 

When specifying the abstract machine it is convenient first to present its configu- 
rations and next its instructions and their meanings. 

The abstract machine AM has configurations of the form (c, e, s) where 

• c is the sequence of instructions (or code) to be executed, 

• e is the evaluation stack, and 

• s is the storage. 

We use the evaluation stack to evaluate arithmetic and boolean expressions. For- 
mally, it is a list of values, so writing 
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Stack = (Z U T)* 

we have e £ Stack. For the sake of simplicity we shall assume that the storage 
is similar to the state, that is s £ State, and it is used to hold the values of 
variables. 

The instructions of AM are given by the abstract syntax 
inst ::— PUSH-n | ADD | mult | SUB 

TRUE | FALSE EQ | LE AND | NEG 
FETCH- £ | STORE- £ 

NOOP | branch(c, c) I loop(c, c) 
c ::= e \ inst:c 

where e is the empty sequence. We shall write Code for the syntactic category of 
sequences of instructions, so c is a meta-variable ranging over Code. Therefore 
we have 

(c, e, s) £ Code x Stack x State 

A configuration is a terminal (or final) configuration if its code component is the 
empty sequence, that is if it has the form {e, e, s). 

The semantics of the instructions of the abstract machine is given by an oper- 
ational semantics. As in the previous chapter it will be specified by a transition 
system. The configurations have the form (c, e, s) as described above and the 
transition relation [> specifies how to execute the instructions: 

(c, e, s) > (c ; , e', s') 

The idea is that one step of execution will transform the configuration (c, e, s) 
into (c', e', s'). The relation is defined by the axioms of Table 3.1 where we 
(ambiguously) use the notation ':' both for appending two instruction sequences 
and for prepending an element to a sequence. The evaluation stack is represented 
as a sequence of elements. It has the top of the stack to the left and we shall write 
e for the empty sequence. 

In addition to the usual arithmetic and boolean operations we have six instruc- 
tions that modify the evaluation stack: The operation PUSH-n pushes a constant 
value n onto the stack and true and false push the constants tt and ff, respec- 
tively, onto the stack. The operation FETCH-a; pushes the value bound to x onto 
the stack whereas store- a; pops the topmost element off the stack and updates the 
storage so that the popped value is bound to x. The instruction branch(ci, c 2 ) 
will also change the flow of control: If the top of the stack is the value tt (that is 
some boolean expression has been evaluated to true) then the stack is popped and 
Ci is to be executed next. Otherwise, if the top element of the stack is ff then it 
will be popped and c 2 will be executed next. 
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/ D T T C XT ■ /j o\ 

\y Ubrl- fl. C, e, t> i 


i\ / 

L> \ 


c, 7V [nj.e, s) 




(add:c, Zi:z 2 :e, s) 


[> ( 


c, (z 1 +z 2 )-e, s) 


11 Zi, £ 2 fcZi 


(mult:c, Zi.Z2'.e, s) 


> ( 


c, (z 1 -kz 2 ):e, s) 


it 21, Z 2 £Z 


(SUB:C, Zi'.Z2'G, s) 


[> ( 


c, (z 1 -z 2 ):e, s) 


11 2i, Z 2 fcZ 


/ ' 1 ' T ~> T TT7 1 ■ *"> /D f> \ 

\ i kue. c, e, 6y 


i\ / 
L> \ 


c, tt: 6, >s) 




\ FALSE: c, e, s) 


[> ( 


c, ff:e, 5} 




(EQ:c, Zi:z 2 :e, 5) 


> ( 


c, {z\=z 2 ) m -e, s) 


11 Zi, £ 2 fcZ 






c, (2i<z 2 ):e, 5) 


if Zi, z 2 eZ 


(and:c, ti.t^.e, s) 


> 






( (c tt • e h) 


if £i = 


=tt and £ 2 =tt 




1 (c S ■ e s) 


if * 1 = 


=ff or i 2 =ff, £ 2 eT 


(NEG:c, £:e, 5) 


►I 


(c,ff : e,a) 
(c, tt : e, 5) 


if J=tt 
if £=fT 


(fetch-x:c, e, 5) 


[> (c, (5 x):e, 5) 




\ 1 UxVCj-X . C, /S.t, 0/ 


> ( 


c, e, >jzr]) 


if zez 


/NOOPT P <i\ 

\ IN V_y V_y _L • 5 5 / 


> ( 


c, e, 5) 




(branch(ci, c 2 ):c, t:e, s) 


•I 


(ci : c, e,s) 
k (c 2 : c, e,a) 


if J=tt 
if £=ff 


(loop(ci, c 2 ):c, e, s) 


> 






(ci:BRANCH(c 2 :LOOP| 


Ci, c 2 ), NOOP):c, 


e, 5) 



Table 3.1: Operational semantics for AM 



There are two instructions that change the flow of control. The instruction 
branch(ci, c 2 ) will be used to implement the conditional: as described above 
it will choose the code component Ci or c 2 depending on the current value on 
top of the stack. If the top of the stack is not a truth value the machine will 
halt as there is no next configuration (since the meaning of branch(- • -,- • •) is 
not defined in that case). A looping construct such as the while-construct of 
While can be implemented using the instruction loop(ci, c 2 ). The semantics 
of this instruction is defined by rewriting it to a combination of other constructs 
including the BRANCH-instruction and itself. We shall see shortly how this can be 
used. 

The operational semantics of Table 3.1 is indeed a structural operational se- 
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mantics for AM. Corresponding to the derivation sequences of Chapter 2 we shall 
define a computation sequence for AM. Given a sequence c of instructions and a 
storage s, a computation sequence for c and s is either 

• a finite sequence 

7o, 7i, 72, • • • , 7k 

of configurations satisfying 70 = (c, e, s) and 71 t> 7i + i for 0<i<k, k>0, and 
where there is no 7 such that 7k > 7, or it is 

• an infinite sequence 

7o, 7i, 72, • • • 

of configurations satisfying 70 = (c, e, 5} and 7i > 7i + i for 0<i. 

Note that initial configurations always have an empty evaluation stack. A compu- 
tation sequence is 

• terminating if and only if it is finite, and 

• looping if and only if it is infinite. 

A terminating computation sequence may end in a terminal configuration (that is 
a configuration with an empty code component) or in a stuck configuration (for 
example (add, e, s)). 

Example 3.1 Consider the instruction sequence 

PUSH-l:FETCH-x:ADD:STORE-X 

Assuming that the initial storage s has s x = 3 we get 

(PUSH-l:FETCH-x:ADD:STORE-X, £, s) 

> (FETCH-x:ADD:STORE-x, 1, s) 

> (ADD:STORE-x, 3:1, s) 
t> (STORE-x, 4, s) 

> {e, £, s[xi->4]) 

The computation now stops because there is no next step. This is an example of 
a terminating computation sequence. □ 

Example 3.2 Consider the code 
loop(true, noop) 
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We have 

(loop(true, noop), s, s) 

> (true:branch(noop:loop(true, noop), noop), £, s) 

> (branch(noop:loop(true, noop), noop), tt, s) 
D> (noop:loop(true, noop), £, s) 

D> (loop(true, noop), £, s) 

> ■ ■ ■ 

and the unfolding of the LOOP-instruction is repeated. This is an example of a 
looping computation sequence. □ 

Exercise 3.3 Consider the code 

PUSH-0:STORE-z:FETCH-x:STORE-r: 

LOOP(FETCH-r:FETCH-y:LE, 

FETCH-y:FETCH-r:SUB:STORE-r: 

PUSH-l:FETCH-z:ADD:STORE-z) 

Determine the function computed by this code. □ 
Properties of AM 

The semantics we have specified for the abstract machine is concerned with the 
execution of individual instructions and is therefore close in spirit to the structural 
operational semantics studied in Chapter 2. When proving the correctness of the 
code generation we shall need a few results analogous to those holding for the 
structural operational semantics. As their proofs follow the same lines as those 
for the structural operational semantics we shall leave them as exercises and only 
reformulate the proof technique from Section 2.2: 



Induction on the Length of Computation Sequences 



1: Prove that the property holds for all computation sequences of length 0. 

2: Prove that the property holds for all other computation sequences: As- 
sume that the property holds for all computation sequences of length at 
most k (this is called the induction hypothesis) and show that it holds for 
computation sequences of length k+1. 



The induction step of a proof following this technique will often be done by a case 
analysis on the first instruction of the code component of the configuration. 
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Exercise 3.4 (Essential) By analogy with Exercise 2.21 prove that 

if (ci, ex, s) > k (c', e', s') then (ci:c 2 , e 1 :e 2 - l s) O k (c':c 2 , e':e 2 , s') 

This means that we can extend the code component as well as the stack component 
without changing the behaviour of the machine. □ 

Exercise 3.5 (Essential) By analogy with Lemma 2.19 prove that if 

( Cl :c 2 , e, s) > k (e, e", s") 

then there exists a configuration (e, e', s') and natural numbers k x and k 2 with 
ki+k 2 =k such that 

(ci, e, s) > kl (e, e', s') and (c 2 , e', s') > k2 (e, e", a") 

This means that the execution of a composite sequence of instructions can be split 
into two pieces. □ 

The notion of determinism is defined as for the structural operational semantics. 
So the semantics of an abstract machine is deterministic if for all choices of 7, 7' 
and 7": 

7 > 7' and 7 t> 7" imply 7' = 7" 

Exercise 3.6 (Essential) Show that the machine semantics of Table 3.1 is de- 
terministic. Deduce that there is exactly one computation sequence starting in a 
configuration (c, e, s). □ 

The execution function M. 

We shall define the meaning of a sequence of instructions as a (partial) function 
from State to State: 

M: Code ->■ (State ^ State) 

It is given by 

s' if (c, e, s) >* (e, e, s') 



M[cj s = 



undef otherwise 



The function is well-defined because of Exercise 3.6. Note that the definition does 
not require the stack component of the terminal configuration to be empty but it 
does require the code component to be so. 

The abstract machine AM may seem far removed from more traditional ma- 
chine architectures. In the next few exercises we shall gradually bridge this gap. 



3.2 Specification of the translation 
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Exercise 3.7 AM refers to variables by their name rather than by their address. 
The abstract machine A Mi differs from AM in that 

• the configurations have the form (c, e, m) where c and e are as in AM and 
m, the memory, is a (finite) list of values, that is m G Z*, and 

• the instructions fetch- £ and store- a; are replaced by instructions GET-n 
and PUT-n where n is a natural number (an address). 

Specify the operational semantics of the machine. You may write m[n] to select 
the nth value in the list m (when n is positive but less than or equal to the length 
of m). What happens if we reference an address that is outside the memory? □ 

Exercise 3.8 The next step is to get rid of the operations branch(- • -,- • •) and 
loop(- • -,- • •). The idea is to introduce instructions for defining labels and for 
jumping to labels. The abstract machine AM 2 differs from AMi (of Exercise 3.7) 
in that 

• the configurations have the form (pc, c, e, m) where c, e and m are as before 
and pc is the program counter (a natural number) pointing to an instruction 
in c, and 

• the instructions branch(- • -,- • •) and loop(- • -,- • •) are replaced by the in- 
structions label-/, jump-/ and jumpfalse-/ where / is a label (a natural 
number). 

The idea is that we will execute the instruction in c that pc points to and in most 
cases this will cause the program counter to be incremented by 1. The instruc- 
tion LABEL-/ has no effect except updating the program counter. The instruction 
JUMP-/ will move the program counter to the unique instruction LABEL-/ (if it 
exists). The instruction jumpfalse-/ will only move the program counter to the 
instruction LABEL-/ if the value on top of the stack is ff; if it is tt the program 
counter will be incremented by 1. 

Specify an operational semantics for AM 2 . You may write c[pc] for the in- 
struction in c pointed to by pc (if pc is positive and less than or equal to the 
length of c). What happens if the same label is defined more than once? □ 

Exercise 3.9 Finally, we shall consider an abstract machine AM 3 where the la- 
bels of the instructions jump-/ and jumpfalse-/ of Exercise 3.8 are absolute ad- 
dresses; so jump-7 means jump to the 7th instruction of the code (rather than to 
the instruction label- 7). Specify the operational semantics of the machine. What 
happens if we jump to an instruction that is not in the code? □ 

3.2 Specification of the translation 

We shall now study how to generate code for the abstract machine. 
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Expressions 

Arithmetic and boolean expressions will be evaluated on the evaluation stack of 
the machine and the code to be generated must effect this. This is accomplished 
by the (total) functions 

CA: Aexp -> Code 

and 



CB: Bexp ->■ Code 

specified in Table 3.2. Note that the code generated for binary expressions consists 



CA{nj 


= PUSH-n 


CAM 


= FETCH- X 


CA[a 1 +a 2 \ 


= £4[a 2 ]:C.4[ai]:ADD 


CAlat * a 2 j 


= £4[a 2 ]:£4[ai]:MULT 


CA{a 1 -a 2 \ 


= CA[a 2 \:CA[a 1 ]:SUB 


C£[true] 


— TRUE 


CS[false] 


= FALSE 


CB[ ai = o 2 ] 


= £4[a 2 ]:£4[ai]:EQ 


CB[ ai <a 2 ] 


= C4[a 2 ]:C.4[ai]:LE 


CB[-.6] 


= CB[6]:NEG 


CB[6iA6 2 ] 


= CB[6 2 ]:CB[&i]:AND 



Table 3.2: Translation of expressions 



of the code for the right argument followed by that for the left argument and 
finally the appropriate instruction for the operator. In this way it is ensured 
that the arguments appear on the evaluation stack in the order required by the 
instructions (in Table 3.1). Note that CA and CB are defined compositionally. 

Example 3.10 For the arithmetic expression x+1 we calculate the code as fol- 
lows: 

£A[x+l] = £A[l]:£A[x]:ADD = PUSH-l:FETCH-z:ADD □ 

Exercise 3.11 It is clear that ^4|(ai + a 2 ) + a3] equals ^4|ai + (a 2 +a 3 )]. Show that 
it is not the case that C^4|(ai+a 2 )+a3] equals C^4|ai+(a 2 +a 3 )]. Nonetheless, 
show that C^4f (ai+a 2 )+a 3 ] and C^4|ai+(a 2 +a3)] do in fact behave similar to one 
another. □ 
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Statements 

The translation of statements into abstract machine code is given by the (total) 
function 



CS: Stm ->■ Code 

specified in Table 3.3. The code generated for an arithmetic expression a ensures 



CS[x := aj 


= CA{a]:STOKE-x 


CSJskip] 


— NOOP 


C5[5i;5 2 ] 


= C5[5i]:C5[5 2 ] 


CS[if b then Si else S 2 j 


= CB[6]:branch(CS[Si],CS[S 2 ]) 


CS [while b do S] 


= loop(CB[6],CS[S]) 



Table 3.3: Translation of statements in While 



that the value of the expression is on top of the evaluation stack when it has 
been computed. So in the code for x := a it suffices to append the code for a 
with the instruction STORE- a;. This instruction assigns x the appropriate value 
and additionally pops the stack. For the skip-statement we generate the noop- 
instruction. For sequencing of statements we just concatenate the two instruction 
sequences. When generating code for the conditional, the code for the boolean 
expression will ensure that a truth value will be placed on top of the evaluation 
stack and the BRANCH-instruction will then inspect (and pop) that value and 
select the appropriate piece of code. Finally, the code for the while-construct uses 
the LOOP-instruction. Again we may note that CS is defined in a compositional 
manner. 

Example 3.12 The code generated for the factorial statement considered earlier 
is as follows: 

CS{y:—l; while -i(x=l) do (y:=y * x; x:=x— 1)] 

= C5[y:=l]:C5[while ->(x=l) do (y:=y * x; x:=x-l)] 

= C^[l]:STORE-y:LOOP(C#Hx=l)],C<%:=y * x; x:=x-l]) 

= PUSH-l:STORE-y:LOOP(CB[x=l]:NEG,C5[y:=y * x]:C5[x:=x-l]) 

= PUSH-l:STORE-y:LOOP(PUSH-l:FETCH-x:EQ:NEG, 

FETCH-x:FETCH-y:MULT:STORE-y: 

PUSH-l:FETCH-x:SUB:STORE-x) □ 
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Exercise 3.13 Use CS to generate code for the statement 

z:=0; while y<x do (z:=z+l; x:=x— y) 

Trace the computation of the code starting from a storage where x is 17 and y 
is 5. □ 



Exercise 3.14 Extend While with the construct repeat S until b and specify 
how to generate code for it. Note that the definition has to be compositional and 
that it is not necessary to extend the instruction set of the abstract machine. □ 

Exercise 3.15 Extend While with the construct for x :— Oi to a 2 do S and 

specify how to generate code for it. As in Exercise 3.14 the definition has to be 
compositional but you may have to introduce an instruction COPY that duplicates 
the element on top of the evaluation stack. □ 



The semantic function <S am 

The meaning of a statement S can now be obtained by first translating it into 
code for AM and next executing the code on the abstract machine. The effect of 
this is expressed by the function 

<S am : Stm -> (State <^-> State) 

defined by 

S am {S] = (M°CS)[S] 



Exercise 3.16 Modify the code generation so as to translate While into code for 
the abstract machine AMi of Exercise 3.7. You may assume the existence of a 
function 



env: Var — > N 



that maps variables to their addresses. Apply the code generation function to the 
factorial statement of Exercise 1.1 and execute the code so obtained starting from 
a memory where x is 3. □ 

Exercise 3.17 Modify the code generation so as to translate While into code for 
the abstract machine AM 2 of Exercise 3.8. Be careful to generate unique labels, 
for example by having "the next unused label" as an additional parameter to the 
code generation functions. Apply the code generation function to the factorial 
statement and execute the code so obtained starting from a memory where x has 
the value 3. □ 
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3.3 Correctness 

The correctness of the implementation amounts to showing that, if we first trans- 
late a statement into code for AM and then execute that code, then we must 
obtain the same result as specified by the operational semantics of While. 

Expressions 

The correctness of the implementation of arithmetic expressions is expressed by 
the following lemma: 

Lemma 3.18 For all arithmetic expressions a we have 

(CAM, e, s) >* (e, Afajs, s) 

Furthermore, all intermediate configurations of this computation sequence will 
have a non-empty evaluation stack. 

Proof: The proof is by structural induction on a. Below we shall give the proof 
for three illustrative cases, leaving the remaining ones as an exercise. 

The case n: We have CAJn] = PUSH-n and from Table 3.1 we get 

(puSH-n, e, s) t> (e, A/"[n], s) 

Since ^4[n]5 = A/"[n] (see Table 1.1) we have completed the proof in this case. 
The case x: We have = fetch- £ and from Table 3.1 we get 

(fetch-o;, e, s) > (e, (s x), s) 

Since ^4|£]<s — s x this is the required result. 

The case di+a 2 : We have C4[ai + a 2 ] = C^4[a 2 ]:C^4[ai]:ADD. The induction 
hypothesis applied to a\ and a 2 gives that 

<£A[ai], e, s) >* (e, Afa^s, s) 

and 

(CA[a 2 ], e, s) >* (e, A{a 2 \s, s) 

In both cases all intermediate configurations will have a non-empty evaluation 
stack. Using Exercise 3.4 we get that 

(C4[a 2 ]:C4[ai]:ADD, e, s) >* (C^4[ai]:ADD, -4[a 2 ]s, s) 

Applying the exercise once more we get that 



74 



3 Provably Correct Implementation 



(OA[ai]:ADD, A[a 2 ]s, s) >* (add, (^[oi]s):(^[o 2 ]s), s) 

Using the transition relation for ADD given in Table 3.1 we get 

(add, (^[oi]a):(^[o 2 ]a), s) > (e, ^[oi]s+^[o 2 ]s, 5) 

It is easy to check that all intermediate configurations have a non-empty evaluation 
stack. Since ^4[ai+a 2 ]<s = .4|ai]s + ^4[a 2 ]s we have the desired result. □ 

We have a similar result for boolean expressions: 

Exercise 3.19 (Essential) Show that for all boolean expressions b we have 

(CB[b], e, s) >* (e, B[b]s, s) 

Furthermore, show that all intermediate configurations of this computation se- 
quence will have a non-empty evaluation stack. □ 

Statements 

When formulating the correctness of the result for statements we have a choice 
between using 

• the natural semantics, or 

• the structural operational semantics. 

Here we shall use the natural semantics but in the next section we sketch the proof 
in the case where the structural operational semantics is used. 

The correctness of the translation of statements is expressed by the following 
theorem: 

Theorem 3.20 For every statement S of While we have tSnsI'S'] — <S am [<Sl. 

This theorem relates the behaviour of a statement under the natural semantics 
with the behaviour of the code on the abstract machine under its operational 
semantics. In analogy with Theorem 2.26 it expresses two properties: 

• If the execution of S from some state terminates in one of the semantics then 
it also terminates in the other and the resulting states will be equal. 

• Furthermore, if the execution of S from some state loops in one of the se- 
mantics then it will also loop in the other. 

The theorem is proved in two stages as expressed by Lemmas 3.21 and 3.22 below. 
We shall first prove: 
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Lemma 3.21 For every statement S of While and states s and s', we have that 

if (S, s) -> s' then (CS[S], e, s) >* (e, e, s') 

So if the execution of S from 5 terminates in the natural semantics then the 
execution of the code for S from storage s will terminate and the resulting states 
and storages will be equal. 

Proof: We proceed by induction on the shape of the derivation tree for {S, s)—>s'. 
The case [ass ns ]: We assume that 

(x: — a, s)—>s' 
where s'=s[:z:i— hAJaJs]. From Table 3.3 we have 

CS{x:=a\ = CAlaf.STOKErX 
From Lemma 3.18 applied to a we get 

(CA[a], e, s) >* (e, A[a]s, s) 

and then Exercise 3.4 gives the first part of 

(CA[a]:STORE-x, £, s) >* (STORE-x, (AJaJs), s) 

> (e, e, s[xh^A{a}s]} 

and the second part follows from the operational semantics for store- a; given in 
Table 3.1. Since s' = 5[xM-A[a]5] this completes the proof. 

The case [skip ns ]: Straightforward. 

The case [comp ns ]: Assume that 

<5i;5 2 , s) s" 
holds because 

(S u s) s' and (S 2 , s') -)• s" 
From Table 3.3 we have 

C5[5i;5 2 ] = C5[5i]:C5[5 2 ] 

We shall now apply the induction hypothesis to the premises {Si, s) — > s' and 
{S2, s') — > 5" and we get 

e, a) >* (e, e, a') 
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and 

(CS[S 2 ], e, s') >* (e, e, a") 
Using Exercise 3.4 we then have 

<CS[Si]:CS[S 2 ], e, s) >* (CS[S 2 ], e, a') >* (e, e, s") 
and the result follows. 
The case [if**] : Assume that 

(if b then Si else S 2 , s) — > a' 
because #[6]s = tt and 

(Si, s) -> a' 
From Table 3.3 we get that 

C5[if 6 then Si else 5 2 ] = C£[6]:BRANCH(C«S[Si], C<S[S 2 ]) 
Using Exercises 3.19 and 3.4 we get the first part of 

<CB[6]:branch(CS[Si], eS[S 2 \), e, s) 

>* (branch(C5[5i], CS[S 2 \), (B[b}s), s) 
> <C5[5i],e >a > 

>* (e, e, 

The second part follows from the definition of the meaning of the instruction 
branch in the case where the element on top of the evaluation stack is tt (which 
is the value of The third part of the computation sequence comes from 

applying the induction hypothesis to the premise {Si, s) — > s'. 

The case [if^]: Analogous. 

The case [while**]: Assume that 

(while b do S, a) ->■ a" 
because #[&]<s = tt, 

(S, s) ->■ a' and (while b do 5", s') ->■ s" 
From Table 3.3 we have 

CSJwhile b do SJ = loop(CB[6], C5[5]) 
and get 
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<loop(CB[6], CS[S\), e, s) 

> (C£[6]:branch(CS[S]:loop(CB[6], CS[S]), noop), e, s) 
>*(branch(C5[5]:loop(CS[6], C5[5]), noop), (B[6]a), 5) 

> <CS[S]:loop(CB[6], CS[S\), e, s) 

Here the first part follows from the meaning of the LOOP-instruction (see Table 3.1) 
and the second part from Exercises 3.19 and 3.4. Since = tt the third part 

follows from the meaning of the BRANCH-instruction. The induction hypothesis 
can now be applied to the premises {S, s) — > s' and (while b do S, s') — > s" and 
gives 

(CS[S\, e, s) >* {e, e, s>) 
{LOOP(CB[b}, CS[S\), e, s') >* (e, e, s") 

so using Exercise 3.4 we get 

<C5[5]:loop(CB[6], CS[S\), e, s) 

>* <loop(CB[6], CS[S\), e, s') 

>* (e, e, s") 

The case [while^]: Assume that (while b do S, s) — > s' holds because B[6]s = ff 
and then s — s'. We have 

<loop(CB[6], CS[S\), e, s) 

> (CB[b]:BRANCH(CS[S]:LOOP(CB[b], CS[S]), noop), e, s) 
>*<BRANCH(C5[5]:LOOP(CiB[6], CS[S]), noop), (B[b]s), s) 

> (noop, e, s) 

using the definitions of the LOOP-, BRANCH- and NOOP-instructions in Table 3.1 
together with Exercises 3.19 and 3.4. □ 

This proves Lemma 3.21. The second part of the theorem follows from: 



Lemma 3.22 For every statement S of While and states s and s', we have that 

if (CS[S\, e, s) > k (e, e, s') then (S, s) ->■ s' and e = e 

So if the execution of the code for S from a storage s terminates then the natural 
semantics of S from s will terminate in a state being equal to the storage of the 
terminal configuration. 
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Proof: We shall proceed by induction on the length k of the computation sequence 
of the abstract machine. If k = the result holds vacuously because CtSJS 1 ] = £ 
cannot occur. So assume that it holds for k < k and we shall prove that it holds 
for k = k +l. We proceed by cases on the statement S. 

The case x: — a: We then have CS\x :— a] = CAJajiSTORE-z so assume that 

(£A[a]:STORE-x, s, s) > k o +1 (e, e, a') 

Then by Exercise 3.5 there must be a configuration of the form {e, e", s") such 
that 

(CA[a], e, s) >^ (e, e", s") 
(store-z, e", a") > k2 {e, e, a') 

where ki + k 2 = k + 1. From Lemma 3.18 and Exercise 3.6 we get that e" must 
be (^4|a],s) and s" must be s. Using the semantics of store- a; we therefore see 
that s' is s[x\- >A{a}s] and e is e. It now follows from [ass ns ] that {x:—a, s)—>s'. 

The case skip: Straightforward. 

The case Si,S2- Assume that 

<C5[5i]:C5[5 2 ], e, s) > ko+1 (e, e, s") 
Then by Exercise 3.5 there must be a configuration of the form {e, e', s ! ) such that 

<C5[5i], e, s) >^ (e, e', a') 
(CS[S 2 ], e', s') > k2 (e, e, a") 

where ki + k 2 = k + 1. The induction hypothesis can now be applied to the first 
of these computation sequences because ki < k and gives 

{Si, s) — > s' and e' — e 

Thus we have (CtSJS^l, £, s') > k2 {e, e, s") and since k 2 < k the induction 
hypothesis can be applied to this computation sequence and gives 

{S2, s') — > s" and e = e 

The rule [comp ns ] now gives {S\\Si, s) — > s" as required. 

The case if b then Si else ,S , 2 : The code generated for the conditional is 

CB[6]:branch(CS[Si], CS[S 2 ]) 

so we assume that 

<CiB[6]:BRANCH(C5[5i], CS[S 2 \), e, s) > ko+1 {e, e, s') 
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Then by Exercise 3.5 there must be a configuration of the form (e, e", s") such 
that 

(CB[b], e, s) >"i (e, e", s") 

and 

<branch(C5[5i], CS[S 2 ]), e", s") > k2 (e, e, s') 

where ki + k 2 = k + 1. From Exercises 3.19 and 3.6 we get that e" must be 
and s" must be s. We shall now assume that = tt. Then there must 

be a configuration (C5[5i], e, s) such that 

(C5[5i], e, s) >"«-i (e, e, a') 

The induction hypothesis can now be applied to this computation sequence because 
k 2 — 1 < k and we get 

{Si, s) — > s' and e = e 

The rule [if**] gives the required (if b then Si else S2, s) — > s'. The case where 
= ff is similar. 

The case while b do S: The code for the while-loop is loop(CB[6], CS[S\) and 
we therefore assume that 

<loop(GB[&], CS[S\), e, s) > k ° +1 {e, e, s") 

Using the definition of the LOOP-instruction this means that the computation 
sequence can be rewritten as 

<loop(CB[6], CS[S\), e, s) 

> <CiB[6]:BRANCH(C5[5]:LOOP(CS[6], CS{S]), noop), e, s) 
> ko (e, e, s") 

According to Exercise 3.5 there will then be a configuration {e, e', s') such that 
{CB[b}, s) >^ (e, e', s>) 

and 

<BRANCH(C5[5]:LOOP(CiB[6], CS[S\), noop), e', s') > k2 (e, e, s") 

where ki + k 2 = k . From Exercises 3.19 and 3.6 we get e' — B{b}s and s' — s. 
We now have two cases. 

In the first case assume that = ff. We then have 
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<branch(C<S[S]:loop(C£[&], CS{S]), noop), B{b]s, s) 
D> (noop, e, s) 

soe = £ and 5 = 5". Using rule [while^j] we get (while 6 do S, s) — > 5" as required. 
In the second case assume that = tt. Then we have 

<branch(CS[S]:loop(CB[6], CS[S\), noop), B[b]s, s) 
> (CS[S]:loop(CB[6], C5[5]), e, 5) 

> k2 - 1 (e, e, 5") 

We then proceed very much as in the case of the composition statement and get a 
configuration {e, e', s') such that 

(CS[S\, e, s) > k 3 (e, e', s') 

<loop(CB[6], CS[S\), e', s') >^ (e, e, s") 

where k 3 + k 4 = k 2 — 1. Since k 3 < k we can apply the induction hypothesis to 
the first of these computation sequences and get 

{S, s) — > s' and e' — e 

We can then use that k 4 < k and apply the induction hypothesis to the compu- 
tation sequence (loop(CB[6], C^J^]), e, s') \> u (e, e, s") and get 

(while b do S, s') — > s" and e — e 

Using rule [while^] we then get (while b do S, s) — > s" as required. This completes 
the proof of the lemma. □ 

The proof technique employed in the above proof may be summarized as fol- 
lows: 



Proof Summary for While: 
Correctness of Implementation 



1: Prove by induction on the shape of derivation trees that for each derivation 
tree in the natural semantics there is a corresponding finite computation 
sequence on the abstract machine. 

2: Prove by induction on the length of computation sequences that for each fi- 
nite computation sequence obtained from executing a statement of While 
on the abstract machine there is a corresponding derivation tree in the 
natural semantics. 



3.4 An alternative proof technique 
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Note the similarities between this proof technique and that for showing the equiv- 
alence of two operational semantics (see Section 2.3). Again one has to be careful 
when adapting this approach to a language with additional programming con- 
structs or a different machine language. 

Exercise 3.23 Consider the "optimized" code generation function CS' that is as 
CS of Table 3.3 except that C<S'[skip] = e. Would this complicate the proof of 
Theorem 3.20? □ 

Exercise 3.24 Extend the proof of Theorem 3.20 to hold for the While language 
extended with repeat S until b. The code generated for this construct was 
studied in Exercise 3.14 and its natural semantics in Exercise 2.7. □ 

Exercise 3.25 Prove that the code generated for AMi in Exercise 3.16 is correct. 
What assumptions do you need to make about envl □ 



3.4 An alternative proof technique 

In Theorem 3.20 we proved the correctness of the implementation with respect to 
the natural semantics. It is obvious that the implementation will also be correct 
with respect to the structural operational semantics, that is 

<5 S os[<Sl — ^amji?] for all statements S of While 

because we showed in Theorem 2.26 that the natural semantics is equivalent to 
the structural operational semantics. However, one might argue that it would be 
easier to give a direct proof of the correctness of the implementation with respect 
to the structural operational semantics, because both approaches are based on the 
idea of specifying the individual steps of the computation. We shall comment upon 
this shortly. 

A direct proof of the correctness result with respect to the structural opera- 
tional semantics could proceed as follows. We shall define a bisimulation relation 
~ between the configurations of the structural operational semantics and those of 
the operational semantics for AM. It is defined by 

(S,s) » (CS[S\,e,s) 

s pa {e, e, s) 

for all statements S and states s. The first stage will then be to prove that when- 
ever one step of the structural operational semantics changes the configuration 
then there is a sequence of steps in the semantics of AM that will make a similar 
change in the configuration of the abstract machine: 



Exercise 3.26 * Show that if 
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7sos ~ 7am and 7 S0S => 7^ os 
then there exists a configuration 7' am such that 

7am > + 7am and 7sos ~ Yam 

Argue that this means that if (S, s) =>* s' then (C5J5 1 ], e, s) t>* (e, e, s'). □ 

The second part of the proof is to show that whenever AM makes a sequence 
of moves from a configuration with an empty evaluation stack to another configu- 
ration with an empty evaluation stack, then the structural operational semantics 
can make a similar change of configurations. Note that AM may have to make 
more than one step to arrive at a configuration with an empty stack, due to the 
way it evaluates expressions; in the structural operational semantics, however, 
expressions are evaluated as part of a single step. 

Exercise 3.27 ** Assume that 7 S0S « 7^ and 

7am > 7am > " " " > 7am 

where k>l and only 7^ and 7 am have empty evaluation stacks (that is, are of the 
form (c, e, s)). Show that there exists a configuration 7g 0S such that 

7sos => 7sos and 7sos ~ 7am 

Argue that this means that if (Cc?^], e, s) >* (e, e, s') then {S, s) s'. □ 

Exercise 3.28 Show that Exercises 3.26 and 3.27 together constitute a direct 
proof of tSsosI'?] = «5 am [5], for all statements S of While. □ 

The success of this approach relies on the two semantics proceeding in lock- 
step: that one is able to find configurations in the two derivation sequences that 
correspond to one another (as specified by the bisimulation relation). Often this 
is not possible and then one has to raise the level of abstraction for one of the 
semantics. This is exactly what happens when the structural operational semantics 
is replaced by the natural semantics: we do not care about the individual steps of 
the execution but only on the result. 

The proof technique employed in the above sketch of proof may be summarized 
as follows: 



3.4 An alternative proof technique 



83 



Proof Summary for While: 
Correctness of Implementation using Bisimulation 



1: Prove that one step in the structural operational semantics can be simu- 
lated by a non-empty sequence of steps on the abstract machine. Show 
that this extends to sequences of steps in the structural operational 
semantics. 

2: Prove that a carefully selected non-empty sequence of steps on the ab- 
stract machine can be simulated by a step in the structural operational 
semantics. Show that this extends to more general sequences of steps on 
the abstract machine. 



Again, this method needs to be modified when considering a programming lan- 
guage with additional constructs or a different abstract machine. 

Exercise 3.29 * Consider the following, seemingly innocent, modification of the 
structural operational semantics of Table 2.2 in which [while sos ] is replaced by the 
two axioms: 

(while b do S, s) => (S; while b do S, s) if B[b]s = tt 
(while b do S, s) => s if B[b]s = ff 

Show that the modified semantic function, S' sos , satisfies 

^sosI'S'] — ^gogj^] for all statements S of While 

Investigate whether or not this complicates the proofs of (analogues of) Exercises 
3.26 and 3.27. □ 
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Chapter 4 

Denotational Semantics 



In the operational approach we were interested in how a program is executed. 
This is contrary to the denotational approach where we are merely interested in 
the effect of executing a program. By effect we here mean an association between 
initial states and final states. The idea then is to define a semantic function for 
each syntactic category. It maps each syntactic construct to a mathematical object, 
often a function, that describes the effect of executing that construct. 

The hallmark of denotational semantics is that semantic functions are defined 
compositionally, that is 

• there is a semantic clause for each of the basis elements of the syntactic 
category, and 

• for each method of constructing a composite element (in the syntactic cate- 
gory) there is a semantic clause defined in terms of the semantic function 
applied to the immediate constituents of the composite element. 

The functions A and B defined in Chapter 1 are examples of denotational defini- 
tions: the mathematical objects associated with arithmetic expressions are func- 
tions in State — > Z and those associated with boolean expressions are functions in 
State — > T. The functions S ns and <S S0S associate mathematical objects with each 
statement, namely partial functions in State <^-> State. However, they are not 
examples of denotational definitions because they are not defined compositionally. 

4.1 Direct style semantics: specification 

The effect of executing a statement S is to change the state so we shall define the 
meaning of S to be a partial function on states: 

<S ds : Stm ->• (State ^ State) 
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Sdsl% '■= ajs — s[x\-^A{ajs] 
<S ds [skip] = id 

S ds {Si ; S 2 j = S da lS 2 j o S da {Si} 

5 ds [if b then S 1 else S 2 j = cond(B[6], <S ds [Si], 5 ds [5 2 ]) 
S da [while b do 5] = FIX F 

where F g — cond(#[&], # o 5^ [5], id) 



Table 4.1: Denotational semantics for While 

This is also the functionality of S ns and <S S0S and the need for partiality is again 
demonstrated by the statement while true do skip. The definition is summarized 
in Table 4.1 and we explain it in detail below; in particular, we shall define the 
auxiliary functions 'cond' and FIX. 
For assignment the clause 

S da {x := ojs = s[xh^-A{a]s] 

ensures that if S ds {x :— ajs — s' then s' x — A{a}s and s' y — s y for y^x. The 
clause for skip expresses that no state change takes place: the function id is the 
identity function on State so <Sds[ s kip]<s = s. 
For sequencing the clause is 

S ds {Si ; S 2 j = S ds {S 2 j o S ds {S 1 j 

So the effect of executing Si ; S 2 is the functional composition of the effect of 
executing Si and that of executing S 2 . Functional composition is defined such that 
if one of the functions is undefined on a given argument then their composition is 
undefined as well. Given a state s, we therefore have 

= (S ds {S 2 } o S ds lSi})s 

s" if there exists s' such that tSdsI'S'i] 5 = s' 

and S ds lS 2 }s' = s" 

= < undef if tSdsI'S'i] 5 = undef 

or if there exists s' such that <Sd S ['S , i]<s = s' 

but <5d S [5 , 2]>s' = undef 

It follows that the sequencing construct will only give a defined result if both 
components do. 

For conditional the clause is 
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<S ds [if b then S, else S 2 J = cond(B[6], S^S.J, S ds {S 2 J) 

and the auxiliary function 'cond' has functionality 

cond: (State ->■ T) x (State State) x (State ^ State) 
->■ (State State) 

and is defined by 



The first parameter to 'cond' is a function that, when supplied with an argument, 
will select either the second or the third parameter of 'cond' and then supply that 
parameter with the same argument. Thus we have 



So if the selected branch gives a defined result then so does the conditional. Note 
that since B\bJ is a total function, #[6]s cannot be undef . 

Defining the effect of while b do S is a major task. To motivate the actual 
definition we first observe that the effect of while b do S must equal that of 

if b then (S; while b do S) else skip 

Using the parts of <S ds that have already been defined, this gives 



S ds [while b do SJ = cond(B[6], <S ds [while b do SJ o S ds {SJ, id) (*) 



Note that we cannot use (*) as the definition of <S ds [while b do SJ because then 
<S ds would not be a compositional definition. However, (*) expresses that 

Sds [while b do SJ must be a fixed point of the functional F defined by 



that is <S ds [while b do SJ — F (<S ds [while b do SJ). In this way we will get a 
compositional definition of <S ds because when defining F we only apply <S ds to the 
immediate constituents of while b do S and not to the construct itself. Thus we 
write 




<S ds [if b then 5i else S 2 J s 

= cond(B[6], SdJSJ, S da {S 2 J) s 

■ s' if B[b]s = tt and <S ds [Si]s = s' 

or if B[b]s = ff and S ds lS 2 Js = s' 



< 



undef if #[&]s = tt and cMsJiS'iJs = undef 

or if B[6]s = fF and (Sdsl^l-s = undef 



F g = cond(£[&], g o S ds {SJ, id) 
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S ds [while b do SJ = FIX F 

where F g = cond(#[6], 5 o SdsJS], id) 

to indicate that S^s [while b do SJ is a fixed point of F. The functionality of the 
auxiliary function FIX is 

FIX: ((State «^ State) ->■ (State ^ State)) ->■ (State ^ State) 

Example 4.1 Consider the statement 

while -i(x = 0) do skip 
It is easy to verify that the corresponding functional F' is defined by 



(F' g) s = 



g s if s x 7^ 
5 if s x = 



The function g 1 defined by 



9i s = 



undef if s x ^ 
5 if s x = 



is a fixed point of F' because 

01 s if s x 7^ 
5 11 s x = 
undef if s x ^ 

5 if 5 x = 

= 9i s 

Next we claim that the function g 2 defined by 

g 2 s = undef for all s 

cannot be a fixed point for F'. The reason is that if s' is a state with s' x = 
then (F' g 2 ) s' — s' whereas g 2 s' — undef . □ 

Unfortunately, this does not suffice for defining S^s [while b do SJ. We face 
two problems: 

• there are functional that have more than one fixed point, and 

• there are functional that have no fixed point at all. 
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The functional F' of Example 4.1 has more than one fixed point. In fact, every 
function g' of State <^-> State satisfying g' s — s if sx = will be a fixed point 
of /• '. 

To give an example of a functional that has no fixed points consider F 1 defined 

by 



Fi g = 



9i if 9 = 92 
g 2 otherwise 



If <?i7^<?2 then clearly there will be no function g such that F 1 g — g . Thus F 1 
has no fixed points at all. 

Exercise 4.2 Determine the functional F associated with the statement 

while -i(x=0) do x := x— 1 

using the semantic equations of Table 4.1. Consider the following partial functions 
of State <^-> State: 

5i s = undef for all s 

s[x^O] if s x > 
undef if s x < 



92 s 



93 s 



s[xi-^0] if s x > 
s if s x < 

g^ s — s[xh- >-0] for all s 
g 5 s — s for all s 

Determine which of these functions are fixed points of F. □ 

Exercise 4.3 Consider the following fragment of the factorial statement 

while -i(x=l) do (y := y*x; x :— x— 1) 

Determine the functional F associated with this statement. Determine at least 
two different fixed points for F. □ 

Requirements on the fixed point 

Our solution to the two problems listed above will be to develop a framework 
where 

• we impose requirements on the fixed points and show that there is at most 
one fixed point fulfilling these requirements, and 
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• all functional originating from statements in While do have a fixed point 
that satisfies these requirements. 

To motivate our choice of requirements let us consider the execution of a state- 
ment while b do S from a state Sq. There are three possible outcomes: 

A: it terminates, 

B: it loops locally, that is there is a construct in S that loops, or 

C: it loops globally, that is the outer while-construct loops. 

We shall now investigate what can be said about the functional F and its fixed 
points in each of the three cases. 

The case A: In this case the execution of while b do S from sq terminates. This 
means that there are states si, ■ ■ ■, s n such that 



SdsIS] S i = for i<n 

An example of a statement and a state satisfying these conditions is the statement 

while 0<x do x := x— 1 

and any state where x has a non-negative value. 

Let go be any fixed point of F, that is assume that F g = g . In the case 
where i<n we calculate 




and 



go Si = 



{F go) Si 

cond(B[6], g o S ds {Sj, id) s ; 

#0 (Sda[S] Si) 



= go Si+i 



In the case where i=n we get 



#o s n = 



{F go) s n 

cond(B[6], go ° S *[£!], id) s 



n 



= id s 



n 



S 



n 



Thus every fixed point g of F will satisfy 
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go s = s n 

so in this case we do not obtain any additional requirements that will help us to 
choose one of the fixed points as the preferred one. 

The case B: In this case the execution of while b do S from s loops locally. 
This means that there are states si, ■ ■ -, s n such that 

B{b}si = tt for i<n 

and 



f s i+ i for i<n 
^ undei tor i=n 



An example of a statement and a state satisfying these conditions is the statement 

while 0<x do (if x=0 then (while true do skip) 

else x := x— 1) 

and any state where x has a non-negative value. 

Let g be any fixed point of F, that is F g — g . In the case where i<n we 
obtain 

9o si = g s i+ i 

just as in the previous case. However, in the case where i=n we get 

go s n = (F g ) s n 

= cond(B[6], g ° S ds {Sj : id) s n 
= (go o S ds {Sj) s n 
= undef 

Thus any fixed point #o of F will satisfy 
go so = undef 

so, again, in this case we do not obtain any additional requirements that will help 
us to choose one of the fixed points as the preferred one. 

The case C: The potential difference between fixed points comes to light when we 
consider the possibility that the execution of while b do S from s loops globally. 
This means that there are infinitely many states Si, ■ ■ ■ such that 

B[b]si = tt for all i 

and 
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^dsl^l^i = Sj+i for all i. 

An example of a statement and a state satisfying these conditions is the statement 

while -i(x=0) do skip 

and any state where x is not equal to 0. 

Let go be any fixed point of F, that is F g — g . As in the previous cases we 

get 

9o si = g s i+ i 

for all i>0. Thus we have 

#o so = go Si for all i 

and we cannot determine the value of #0 so in this way. This is the situation in 
which the various fixed points of F may differ. 

This is not surprising because the statement while -i(x=0) do skip of Example 
4.1 has the functional F' given by 



and any partial function g of State <^-> State satisfying gs — s if sx — will 
indeed be a fixed point of F' . However, our computational experience tells us that 
we want 



in order to record the looping. Thus our preferred fixed point of F' is the function 
go defined by 



The property that distinguishes go from some other fixed point g' of F' is that 
whenever g s — s' then we also have g' s — s' but not vice versa. 

Generalizing this experience leads to the following requirement: the desired 
fixed point FIX F should be some partial function g : State State such that 

• go is a fixed point of F, that is F g — go, and 

• if g is another fixed point of F, that is F g = g, then 





undef if s x ^ 
Sq if Sq x = 




g s — s' implies g s = s' 
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for all choices of s and s'. 
Note that if go s — undef then there are no requirements on g s. 

Exercise 4.4 Determine which of the fixed points considered in Exercise 4.2 is 



Exercise 4.5 Determine the desired fixed point of the functional constructed in 



4.2 Fixed point theory 

To prepare for a framework that guarantees the existence of the desired fixed point 
FIX F we shall reformulate the requirements to FIX F in a slightly more formal 
way. The first step will be to formalize the requirement that FIX F shares its 
results with all other fixed points. To do so we define an ordering C on partial 
functions of State <^-> State. We set 



when the partial function gi\ State <^-> State shares its results with the partial 
function g 2 : State <— > State in the sense that 

if gi s = s' then g 2 s = s' 

for all choices of s and s'. 

Example 4.6 Let gi, g 2 , g% and g$ be partial functions in State <^-> State defined 



the desired fixed point, if any. 



□ 



Exercise 4.3. 



□ 



9i E 92 



as follows 



9i s 



s for all s 





undef 



if s x = 



otherwise 



s 



if s x < 



9a s 



undef 



otherwise 



Then we have 
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51 E 5i, 

52 E 5l, 92 E 52, 

53 E 5i, 53 E 52, 53 E 53, 53 E 54, and 

54 E 5i, 54 E 54- 

It is neither the case that g 2 E 54 nor that #4 C g 2 . Pictorially, the ordering may 
be expressed as follows 1 : 




The idea is that the smaller elements are at the bottom of the picture and that the 
lines indicate the order between the elements. However, we shall not draw lines 
when there already is a "broken line", so the fact that g 3 C gi is left implicit in 
the picture. □ 

Exercise 4.7 Let gi, g 2 and g 3 be defined as follows: 

s if s x is even 
undef otherwise 



5i s 



52 s = 

53 s = s 



s if s x is a prime 
undef otherwise 



First, determine the ordering among these partial functions. Next, determine a 
partial function g± such that g± C gi, #4 C g 2 and #4 C #3. Finally, determine a 
partial function g 5 such that 5i ^ 55, 52 ^ 55 and 55 C g 3 but g 5 is neither equal 
to #1, 5-2 nor 53. □ 

Exercise 4.8 (Essential) An alternative characterization of the ordering C on 
State ^ State is 

5i E 52 if and only if graph(#i) C graph(# 2 ) (*) 

where graph(g) is the graph of the partial function g as defined in Appendix A. 
Prove that (*) is indeed correct. □ 



1 Such a diagram is sometimes called a Hasse diagram. 
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The set State <^-> State equipped with the ordering C is an example of a 
partially ordered set as we shall see in Lemma 4.13 below. In general, a partially 
ordered set is a pair (D, n. D ) where D is a set and C fl is a relation on D satisfying 

d Qd d (reflexivity) 
d\ C D d 2 and d 2 C fl d 3 imply c?i C fl d 3 (transitivity) 
di Qd d 2 and d 2 Qd d\ imply o?i = d 2 (anti-symmetry) 

The relation Q D is said to be a partial order on D and we shall often omit the 
subscript D of C fl and write C. Occasionally, we may write c?i □ d 2 instead of 
(i 2 E rfi and we shall say that d 2 shares its information with d\. An element d of 
D satisfying 

d\Zd,' for all d' of D 

is called a least element of i) and we shall say that it contains no information. 



Fact 4.9 If a partially ordered set (D, C) has a least element c? then d is unique. 



Proof: Assume that D has two least elements di and d 2 . Since o?i is a least 
element we have d\ C c? 2 . Since c? 2 is a least element we also have o? 2 C d\. The 
anti-symmetry of the ordering C then gives that d\ — d 2 . □ 

This fact permits us to talk about £/ie least element of D, if one exists, and we 
shall denote it by _I_d or simply _L (pronounced "bottom"). 

Example 4.10 Let S be a non-empty set and define 

V(S) = { K \ K C S } 
Then (V(S), C) is a partially ordered set because 

• C is reflexive: K C K 

• C is transitive: if K\ C K 2 and K 2 C if 3 then K\ C if 3 

• C is anti-symmetric: if K\ C if 2 an d if 2 ^ ^ 1 then if x = if 2 
In the case where S — {a,b,c} the ordering can be depicted as follows: 
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Also, (V(S), C) has a least element, namely 0. □ 

Exercise 4.11 Show that (V(S), ~D) is a partially ordered set and determine the 

least element. Draw a picture of the ordering when S — {a,b,c}. □ 

Exercise 4.12 Let S be a non-empty set and define 

V &Ii (S) = { K | K is finite and K C S } 

Verify that (V& n (S), Q) and (V& n (S), 3) are partially ordered sets. Do both 

partially ordered sets have a least element for all choices of 5? □ 



Lemma 4.13 (State <^-> State, C) is a partially ordered set. The partial function 
_L: State <^-> State defined by 

1 s = undef for all 5 

is the least element of State <^-> State. 



Proof: We shall first prove that C fulfils the three requirements to a partial order: 
Clearly, g IZ g holds because g s — s' trivially implies that g 5 = s' so C is a 
reflexive ordering. 

To see that it is a transitive ordering assume that gi C g 2 and g 2 Q #3 and we 
shall prove that gi C # 3 . Assume that gi s = s'. From ^ C g 2 we get g 2 s = s' 
and then # 2 E <?3 gives that g 3 s — s'. 

To see that it is an anti-symmetric ordering assume that gi C g 2 and g 2 C gi 
and we shall then prove that gi — g 2 . Assume that gi s — s'. Then g 2 s = s' 
follows from ffi C j 2 so 51 and g 2 are equal on s. If gi s — undef then it must be 
the case that g 2 s — undef since otherwise g 2 s = s' and the assumption g 2 C g 1 
then gives gi s — s' which is a contradiction. Thus gi and g 2 will be equal on s. 
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Finally, we shall prove that _L is the least element of State <^-> State. It is 
easy to see that _L is indeed an element of State <^-> State and it is also obvious 
that _L IZ g holds for all g since ± s = s' vacuously implies that g s — s'. □ 

Having introduced an ordering on the partial functions we can now give a more 
precise statement of the requirements to FIX F: 

• FIX F is a fixed point of F, that is F(FIX F) — FIX F, and 

• FIX F is a least fixed point of F, that is 

if F g = g then FIX F \Z g. 

Exercise 4.14 By analogy with Fact 4.9 show that if F has a least fixed point go 
then g is unique. □ 

The next task will be to ensure that all functionals F that may arise do indeed 
have least fixed points. We shall do so by developing a general theory that gives 
more structure to the partially ordered sets and that imposes restrictions on the 
functionals so that they have least fixed points. 

Exercise 4.15 Determine the least fixed points of the functionals considered in 
Exercises 4.2 and 4.3. Compare with Exercises 4.4 and 4.5. □ 



Complete partially ordered sets 

Consider a partially ordered set (D, C) and assume that we have a subset Y of 
D. We shall be interested in an element of D that summarizes all the information 
of Y and this is called an upper bound of Y; formally, it is an element d of D such 
that 

yd' e Y. d' C d 

An upper bound d of Y is a least upper bound if and only if 

d' is an upper bound of Y implies that d C d! 

Thus a least upper bound of Y will add as little extra information as possible to 
that already present in the elements of Y. 

Exercise 4.16 By analogy with Fact 4.9 show that if Y has a least upper bound 
d then d is unique. □ 

If Y has a (necessarily unique) least upper bound we shall denote it by \JY. 
Finally, a subset Y is called a chain if it is consistent in the sense that if we take 
any two elements of Y then one will share its information with the other; formally, 
this is expressed by 
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Vo?i, d 2 6 Y. di C d 2 or c? 2 C di 

Example 4.17 Consider the partially ordered set ("P({a,b,c}), C) of Example 
4.10. Then the subset 

Y = { 0, {a}, {a,c} } 

is a chain. Both {a,b,c} and {a,c} are upper bounds of Y and {a,c} is the least 
upper bound. The element {a,b} is not an upper bound because {a,c} % {a,b}. 
In general, the least upper bound of a non-empty chain in "P({a,b,c}) will be the 
largest element of the chain. 

The subset { 0, {a}, {c}, {a,c} } is not a chain because {a} and {c} are 
unrelated by the ordering. However, it does have a least upper bound, namely 
{a,c}. 

The subset of "P({a,b,c}) is a chain and it has any element of "P({a,b,c}) as 
an upper bound. Its least upper bound is the element 0. □ 

Exercise 4.18 Let S be a non-empty set and consider the partially ordered set 
(V(S), C). Show that every subset of V(S) has a least upper bound. Repeat the 
exercise for the partially ordered set (V(S), 3). □ 

Exercise 4.19 Let S be a non-empty set and consider the partially ordered set 
(Van(S), C) as defined in Exercise 4.12. Show by means of an example that there 
are choices of S such that (Vsn(S), C) has a chain with no upper bound and 
therefore no least upper bound. □ 

Example 4.20 Let g n : State <^-> State be defined by 

undef if s x > n 
g n s — < s[xi— >■— 1] if < s x and s x < n 
s if s x < 

v 

It is straightforward to verify that g n C g m whenever n < m because g n will be 
undefined for more states than g m . Now define Y to be 

Y = { 9n I n > } 
Then F is a chain because g n C g m whenever n < m. The partial function 

f s[x^-l] if < s x 

9 s — { 

[ s if s x < 

is the least upper bound of Y. □ 
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Exercise 4.21 Construct a subset Y of State State such that Y has no 
upper bound and hence no least upper bound. □ 

Exercise 4.22 Let g n be the partial function defined by 

{s[yi— >(s x)!][xi->1] if < s x and s x < n 
undef ifsx<Oor<sx>n 

(where ml denotes the factorial of m.) Define Y — { g n | n > } and show that 
it is a chain. Characterize the upper bounds of Y and determine the least upper 
bound. □ 

A partially ordered set (D, C) is called a chain complete partially ordered set 
(abbreviated ccpo) whenever |JF exists for all chains Y. It is a complete lattice 
if U Y exists for all subsets Y of D. 

Example 4.23 Exercise 4.18 shows that (V(S), C) and (V(S), ~D) are complete 
lattices, and hence ccpo's, for all non-empty sets S. Exercise 4.19 shows that 
(P&n(S), C) need not be a complete lattice nor a ccpo. □ 



Fact 4.24 If (D, C) is a ccpo then it has a least element _L given by _L= |_J0. 



Proof: It is straightforward to check that is a chain and since (D, C) is a ccpo 
we get that |_J0 exists. Using the definition of |_J0 we see that for any element d of 
D we have |_J0 C d. This means that |_J0 is the least element of D. □ 

Exercise 4.21 shows that State State is not a complete lattice. Fortunately, 
we have 



Lemma 4.25 (State <^-> State, C) is a ccpo. The least upper bound \_\Y of a 
chain Y is given by 

graph(Ljr) = U{ graph(#) | g eY } 

that is (U Y)s — s' if and only if g s = s' for some g £ Y. 

Proof: The proof is in three stages: First we prove that 

U{ graph(^) g £ Y } (*) 

is indeed a graph of a partial function in State <^-> State. Secondly, we prove 
that this function will be an upper bound of Y and thirdly that it is less than any 
other upper bound of Y, that is it is the least upper bound of Y . 

To verify that (*) specifies a partial function we only need to show that if {s, s') 
and {s, s") are elements of 
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X = U{ graph^) | geY } 

then s' — s" . When (s, s') £ X there will be a partial function g £ F such that 
g s — s'. Similarly, when (s, 5") £ X then there will be a partial function g' £ F 
such that g' s = s". Since F is a chain we will have that either g ^ g' or g' \Z g. 
In any case we get g s — g' s and this means that 5' = s" as required. This 
completes the first part of the proof. 

In the second part of the proof we define the partial function g by 

graph(^o) = U{ graph(#) g £ F } 

To show that g is an upper bound of F let g be an element of F. Then we have 
graph(^) C graph(g ) and using the result of Exercise 4.8 we see that g C g as 
required and we have completed the second part of the proof. 

In the third part of the proof we show that go is the least upper bound of F. So 
let <?i be some upper bound of F. Using the definition of an upper bound we get 
that g C gi must hold for all g £ F. Exercise 4.8 gives that graph(g) C graph^x). 
Hence it must be the case that 

U{ graph(^) I g £ F } C graph^) 

But this is the same as graph(g ) C graph^x) and Exercise 4.8 gives that g C gi. 
This shows that <?o is the least upper bound of F and thereby we have completed 
the proof. □ 

Continuous functions 

Let (D, C) and (D', C') be ccpo's and consider a (total) function /: D — > D'. If 
c?i C c? 2 then the intuition is that di shares its information with c? 2 . So when the 
function / has been applied to the two elements o?i and d 2 then we shall expect 
that a similar relationship holds between the results. That is we shall expect that 
/ di C' / d 2 and when this is the case we say that / is monotone. Formally, / is 
monotone if and only if 

di C d 2 implies / di C' / d 2 

for all choices of c?i and d 2 . 

Example 4.26 Consider the ccpo's (V({a,b,c}), C) and (^({d^}), C). The func- 
tion fi. V({a,b,c}) — > V({d,e}) defined by the table 



X 


{a,b,c} {a,b} 


{a,c} 


{b,c} 


{a} 


{b} 


{c} 


fiX 


Re} {d} 


{d,e} 


Re} 


{d} 


{d} 


{e} 



4.2 Fixed point theory 



101 



is monotone: it simply changes a's and b's to d's and c's to e's. 
The function / 2 : "P({a,b,c}) — > "P({d,e}) defined by the table 



X 



{a,b,c} {a,b} {a,c} {b,c} {a} {b} {c} 



f 2 x 



{d} 



{d} {d} {e} {d} {e} {e} {e} 



is not monotone because {b,c} C {a,b,c} but / 2 {b,c} % / 2 {a,b,c}. Intuitively, 
all sets that contain an a are mapped to {d} whereas the others are mapped to 
{e} and since the elements {d} and {e} are incomparable this does not give a 
monotone function. However, if we change the definition such that sets with an a 
are mapped to {d} and all other sets to then the function will be monotone. □ 

Exercise 4.27 Consider the ccpo ("P(N), C). Determine which of the following 
functions in "P(N) — > "P(N) are monotone: 



N\X 



f 2 x 



X U {27} 



hx 



X n {7, 9, 13} 



hx 



{ n £ X I n is a prime } 



hx 



{2*n|«eX} 



□ 



Exercise 4.28 Determine which of the following functionals of 



(State ^ State) ->• (State ^ State) 



are monotone: 



• F g = g 






□ 



The monotone functions have a couple of interesting properties. First we prove 
that the composition of two monotone functions is a monotone function. 
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Fact 4.29 Let (D, Q, (£>', C') and (£>", C") be ccpo's and let /: D ^ D' 
and /': D' —} D" be monotone functions. Then /' o /: D — >- £)" is a monotone 
function. 



Proof: Assume that c?i C d 2 . The monotonicity of / gives that / di C' / d 2 . The 
monotonicity of /' then gives /' (/ o?i) C" /' (/ d 2 ) as required. □ 

Next we prove that the image of a chain under a monotone function is itself a 
chain. 



Lemma 4.30 Let (D, C) and (Z?', C') be ccpo's and let /: D — >■ D' be a monotone 
function. If F is a chain in D then {/<i|<i£F}isa chain in D' . Furthermore, 

□'{/ d | d e Y } n'f(UY) 



Proof: If Y = then the result holds immediately since _L' C' / ±. So assume 
that F ^ 0. We shall first prove that {/<i|<ieF}isa chain in D'. So let d[ 
and o? 2 be two elements of {fd\dEY}. Then there are elements c?i and d 2 
in F such that d\ — f di and d' 2 — f d 2 - Since F is a chain we have that either 
di Q d 2 or d 2 C c?i- In either case we get that the same order holds between d\ 
and o? 2 because of the monotonicity of /. This proves that {/<i|<ieF}isa 
chain. 

To prove the second part of the lemma consider an arbitrary element d of 
F. Then it will be the case that d C |JF. The monotonicity of / gives that 
/ d C' /(U^)- Since this holds for all c? £ F we get that /(U^) is an upper 
bound on { / d \ d £ F }, that is U' { / d \ d £ F } C' f(\J F). □ 

In general we cannot expect that a monotone function preserves least upper 
bounds on chains, that is|J'{/^|^^^} = /(U^)- This is illustrated by the 
following example: 

Example 4.31 From Example 4.23 we get that ("P(N U {a}), C) is a ccpo. Now 
consider the function /: P(N U {a}) ->■ "P(N U {a}) defined by 




X if X is finite 

X U {a} if X is infinite 



Clearly, / is a monotone function: if Xi C X 2 then also / Xi C / X 2 . However, 
/ does not preserve the least upper bounds of chains. To see this consider the set 

F = {{0,l,---,n}|n>0} 
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It consists of the elements {0}, {0,1}, {0,1,2}, • • • and it is straightforward to verify 
that it is a chain with N as its least upper bound, that is U Y — N. When we 
apply / to the elements of Y we get 

U{f X \ X £ F } = IJF = N 
However, we also have 

/(UF)=/N = Nu{a} 
showing that / does not preserve the least upper bounds of chains. □ 

We shall be interested in functions that preserve least upper bounds of chains, 
that is functions / that satisfy 

U'{/ d I deY}=f(UY) 

Intuitively, this means that we obtain the same information independently of 
whether we determine the least upper bound before or after applying the func- 
tion /. 

We shall say that a function /: D — > D' defined on ccpo's (D, C) and (D 1 , C') 
is continuous if it is monotone and 

U'{/ d I deY}=f(UY) 

holds for all non-empty chains Y. If |J{ / d | d £ Y } = f([_\Y) holds for the 
empty chain, that is _L = / _L, then we shall say that / is strict. 

Example 4.32 The function f 1 of Example 4.26 is also continuous. To see this 
consider a non-empty chain Y ofP({a,b,c}). The least upper bound of Y will be 
the largest element, say X , of Y (see Example 4.17). Therefore we have 

fi(UY) = fiX because X = UF 

Q U{ h X | X e Y } because X £ Y 

Using that /i is monotone we get from Lemma 4.30 that \_\{ fi X \ X E Y } 
Q fi (U^)- It follows that fi is continuous. Also, fi is a strict function because 

h = 0- 

The function / of Example 4.31 is not a continuous function because there is 
a chain for which it does not preserve the least upper bound. □ 

Exercise 4.33 Show that the functional F' of Example 4.1 is continuous. □ 

Exercise 4.34 Assume that (D, C) and (D 1 , C') are ccpo's and that /: D — > D' 
satisfies 
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|J'{/ d I d eY }=f(UY) 

for all non-empty chains Y of D. Show that / is monotone. □ 

We can extend the result of Lemma 4.29 to show that the composition of two 
continuous functions will also be continuous: 



Lemma 4.35 Let (D, Q, (£>', C') and (D", C") be ccpo's and let /: D ^ D' 
and /': D' —¥ D" be continuous functions. Then /' o /: Z? — >- D" is a continuous 
function. 

Proof: From Lemma 4.29 we get that /' o / is monotone. To prove that it is 
continuous let Y be a non-empty chain in D. The continuity of / gives 

U'{fd\de Y } =f (UY) 

Since { / d | d £ F } is a (non-empty) chain in D' we can use the continuity of 
/' and get 

U"{ /' d' | d! e { f d | d e Y } } = f (U'{ / d \ d e Y }) 

which is equivalent to 

U"{ f (f d)\de Y}=f'(f(UY)) 
This proves the result. □ 

Exercise 4.36 Prove that if / and /' are strict functions then so is /' o /. □ 
We can now define the required fixed point operator FIX: 

Theorem 4.37 Let /: D — > D be a continuous function on the ccpo (D, C) with 
least element _L. Then 

FIX / = U{ f n 1- I n>0 } 
defines an element of D and this element is the least fixed point of/. 

Here we have used that 

/° = id, and 

/ n+1 = / o / n for n>0 



4.2 Fixed point theory 
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Proof: We first show the wett-definedness of FIX /. Note that /° _L = _L and that 
_L Z d for all d G -D. By induction on n one may show that 

for all d G .D since / is monotone. It follows that flC / m _L whenever n<m. 
Hence { / n _L n>0 } is a (non-empty) chain in D and FIX / exists because D is 
a ccpo. 

We next show that FIX / is a fixed, point, that is / (FIX /) = FIX /. We 
calculate: 

/ (FIX /) = / (U{ / n JL I n>0 }) (definition of FIX /) 

= U{ /(/ n J-) ! n>0 } (continuity of/) 

= U{/ n J_|n>l} 

= U({ f n ^ | n>l } U {±}) (U(F U{Z.}) = |jr 

for all chains Y) 

= U{ / n JL | n>0 } (/° ± = ±) 

= FIX / (definition of FIX /) 

To see that FIX / is the least fixed point assume that d is some other fixed 
point. Clearly _L Z d so the monotonicity of / gives / n _L IZ / n d for n>0 and as d 
was a fixed point we obtain / n _L Z d for all n>0. Hence d is an upper bound of 
the chain { / n _L n>0 } and using that FIX / is the least upper bound we have 
FIX / Z d. ' ' □ 



Example 4.38 Consider the function F' of Example 4.1: 
g s if s x ^ 
s if 5 x = 



(F' g) s = 



We shall determine its least fixed point using the approach of Theorem 4.37. The 
least element _L of State <^-> State is given by Lemma 4.13 and has J_ s = undef 
for all s. We then determine the elements of the set { F' n J_ | n>0 } as follows: 



(F'° ±) s 
(F n ±) s 



(id J_) s 
undef 




(definition of F'° ±) 
(definition of id and _L) 
(definition of F' 1 ±) 

(definition of F' _L) 
(definition of _L) 
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(F 12 _L) s = F' (F n ±) s (definition of F' 2 _L) 

(F' 1 ±) s if s x ^ 

(definition of i* 1 ') 

5 if s x = 

undef if s x ^ 

(definition of F' 1 ±) 

5 if 5 X = 



In general we have F' n _L = F' n+1 _L for n > 0. Therefore 
U{ F' n JL | n>0 } = U {^'° -L, F' 1 _L} = F' 1 _L 

because F'° _L = _L. Thus the least fixed point of F' will be the function 

( undef if s x ^ 

^i s = S 

^ s if s x = 



□ 



Exercise 4.39 Redo Exercise 4.15 using the approach of Theorem 4.37, that is 
deduce the general form of the iterands, F n _L, for the functional, F, of Exercises 
4.2 and 4.3. □ 

Exercise 4.40 (Essential) Let /: D — > D be a continuous function on a ccpo 
(D, Q and let deD satisfy f d Q d. Show that FIX /Ed. □ 

The table below summarizes the development we have performed in order to 
demonstrate the existence of least fixed points: 



Fixed Point Theory 



1: We restrict ourselves to chain complete partially ordered sets — ccpo's. 

2: We restrict ourselves to continuous functions on ccpo's. 

3: We show that continuous functions on ccpo's always have least fixed points 
(Theorem 4.37). 



Exercise 4.41 * Let (£>, C) be a ccpo and define (D— >DJZ') by setting 

/i E' / 2 if and only if j\ d Q f 2 d for all d £ Z? 
Show that (D—t D,Q') is a ccpo and that FIX is "continuous" in the sense that 

FIX (□' T) = U{ FIX / | / e T } 
holds for all non-empty chains T C D^D of continuous functions. □ 



4.3 Direct style semantics: existence 
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Exercise 4.42 ** (For mathematicians) Given a ccpo (D, C) we define an open 
set of D to be a subset Y of D satisfying 

(1) if di^Y and e?i C e? 2 then c? 2 G F, and 

(2) if y' is a non-empty chain satisfying U Y' £ F then there exists an element 
d of y' which also is an element of Y. 

The set of open sets of D is denoted On- Show that this is indeed a topology on 
D, that is show that 

• and D are members of and 

• the intersection of two open sets is an open set, and 

• the union of any collection of open sets is an open set. 



Let (D, C) and (D 1 , C') be ccpo's. A function f:D—}D' is topologically-continuous 
if and only if the function f' 1 : V(D') ->■ V(D) defined by 



maps open sets to open sets, that is specializes to / 1 : Od> — > On- Show that / is a 
continuous function between D and D' if and only if it is a topologically-continuous 



4.3 Direct style semantics: existence 

We have now obtained the mathematical foundations needed to prove that the 
semantic clauses of Table 4.1 do indeed define a function. So consider once again 
the clause 



For this to make sense we must show that F is continuous. To do so we first 
observe that 



f-i(Y') = {deD\f de Y'} 



function between D and D'. 



□ 



S ds [while b do Sj = FIX F 

where F g = cond(#[6], g o ^[.S 1 ], id) 



F g 



Fi (F 2 g) 



where 



Fi g 
F 2 9 



cond(B[6], g, id) 
9 o S ds {Sj 
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Using Lemma 4.35 we then obtain the continuity of F by showing that Fi and F 2 
are continuous. We shall first prove that F 1 is continuous: 



Lemma 4.43 Let g : State <^-> State, p: State — > T and define 

F g = cond(p, g, g ) 
Then F is continuous. 



Proof: We shall first prove that F is monotone. So assume that gi C 52 and we 
shall show that F g 1 \Z F g 2 . It suffices to consider an arbitrary state s and show 
that 

(F gi) s — s' implies (F g 2 ) s — s' 

If p s — tt then (F gi) s — gi s and from g 1 C g 2 we get that gi s = s' implies 
g 2 s — s'. Since (F g 2 ) s — g 2 s we have proved the result. So consider the case 
where p s — ff . Then (F gi) s — g s and similarly (F g 2 ) s = g s and the result 
is immediate. 

To prove that F is continuous let Y be a non-empty chain in State <^-> State. 
We must show that 

F (UY) C U{ Fg I gEY } 

since F (|J Y) □ |J{ F g | ^6 F } follows from the monotonicity of F (see Lemma 
4.30). Thus we have to show that 

graph(F(UF)) C U{ graph(F g) \ gtY } 

using the characterization of least upper bounds of chains in State <^-> State given 
in Lemma 4.25. So assume that (F (U Y)) s — s' and let us determine g £ Y such 
that (F g) s — s'. If p s — ff we have F (\JY) s — go s — s' and clearly, for every 
element g of the non-empty set Y we have (F g) s — g s — s'. If p s — tt then 
we get (F (LJF)) s = (\_\Y) s = s' so (5, s') £ graph(UF). Since 

graph(Ljr) = U{ graph(^) | g£ Y } 

(according to Lemma 4.25) we therefore have g£ Y such that g s — s' and it follows 
that (F g) s — s'. This proves the result. □ 



Exercise 4.44 (Essential) Prove that (in the setting of Lemma 4.43) F defined 
by F g — cond(p, g , g) is continuous, that is 'cond' is continuous in its second 
and third arguments. □ 



4.3 Direct style semantics: existence 
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Lemma 4.45 Let go: State <^-» State and define 

F g = g o g 
Then F is continuous. 



Proof: We shall first prove that F is monotone. If gi C g 2 then graph(<7i) C 
graph(g 2 ) according to Exercise 4.8 so that 

graph(# ) o graph(#i) C graph(# ) o graph(# 2 ) 

and this shows that F g 1 IZ F g 2 . Next we shall prove that F is continuous. If Y 
is a non-empty chain then 

graph(F(UF)) = graph((|jr) o g ) 

= graphic) o graph(|J Y) 
= graph(# ) o U{graph(#) | g£Y} 
= U{graph(# ) o graph(^) | geY} 
= graph(U{F <? | g£Y}) 

where we have used Lemma 4.25 twice. Thus F (\JY) — [_\{F 9 I <?£Y}. □ 

Exercise 4.46 (Essential) Prove that (in the setting of Lemma 4.45) F defined 
by F g = g o g is continuous, that is o is continuous in both arguments. □ 

We have now established the results needed to show that the equations of Table 
4.1 define a function <S ds : 



Proposition 4.47 The semantic equations of Table 4.1 define a total function 
Sd a in Stm — > (State <^-> State). 

Proof: The proof is by structural induction on the statement S. 

The case x := a: Clearly the function that maps a state s to the state s[a:i— hAJaJs] 
is well-defined. 

The case skip: Clearly the function id is well-defined. 

The case Si,S2- The induction hypothesis gives that <5d S [<S'i] and <5>dsl>>2] are 
well-defined and clearly their composition will be well-defined. 

The case if b then Si else 5 2 : The induction hypothesis gives that <5>dsl>>i] 
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and (SdslIiSy are well-defined functions and clearly this property is preserved by 
the function 'cond'. 

The case while b do S: The induction hypothesis gives that cMs!*?] is well-defined. 
The functions F 1 and F 2 defined by 

F 1 g = cond(B[6], g, id) 
F 2 g = g o S ds {Sj 

are continuous according to Lemmas 4.43 and 4.45. Thus Lemma 4.35 gives that 
F g — F 1 (F 2 g) is continuous. From Theorem 4.37 we then have that FIX F is 
well-defined and thereby that S^s [while b do SJ is well-defined. This completes 
the proof. □ 

Example 4.48 Consider the denotational semantics of the factorial statement: 

Sd S [y : = !; while ^( x=1 ) do (y ; =y* x ; x:=x-i)] 

We shall be interested in applying this function to a state so where x has the value 
3. To do that we shall first apply the clauses of Table 4.1 and we then get that 

<S ds [y := 1; while ^(x=l) do (y:=y*x; x:=x-l)] s 
= (FIX F) s [j^l] 

where 

_ | 9 (^ds[y:= y*x; x:=x-l] s) if Bh(x=l)] s = tt 



F g s 

{ s if B[n(x=l)] s = ff 



or, equivalently, 

g (s[y^(s y)*(s x)][x4(« x)-l]) if s x ^ 1 



F g s = 



s if s x = 1 



We can now calculate the various functions F n _L used in the definition of FIX F 
in Theorem 4.37: 



(F° _L) s = undef 

undef if s x ^ 1 
s if s x = 1 

undef if s x ^ 1 and 

5 [y |- K 5 y)* 2 ][ x| ->-i] if s x = 2 

5 if s x = 1 



(F 1 ±) 5 



(F 2 ±) s = « 



4.3 Direct style semantics: existence 
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Thus if x is 1 or 2 then the F 2 _L will give the correct value for y and for all other 
values of x the result is undefined. This is a general pattern: the nth iterand F n _L 
will determine the correct value if it can be computed with at most n unfoldings 
of the while-loop (that is n evaluations of the boolean condition). The general 
formula is 



(F n _L) s = 
We then have 

(FIX F) s = 



undef ifsx<lor<sx>n 
s[yi->(s y)*j- • -*2*l][xM-l] if s x = j and l<j and j<n 



undef if s x < 1 

s[yi— >-(s y)*n- ■ -*2*l][xi— >1] if s x = n and n>l 



So in the state s where x has the value 3 we get that the value computed by the 
factorial statement is 

(FIX F) (a [yi-»l]) y = 1^3*2*l = 6 

as expected. □ 

Exercise 4.49 Consider the statement 

z:=0; while y<x do (z:=z+l; x:=x— y) 
and perform a development analogous to that of Example 4.48. □ 

Exercise 4.50 Show that S^s [while true do skip] is the totally undefined func- 
tion _L. □ 



Exercise 4.51 Extend the language with the statement repeat S until b and 
give the new (compositional) clause for <S ds . Validate the well-definedness of the 
extended version of S^s- 1=1 

Exercise 4.52 Extend the language with the statement for x :— Oi to a 2 d° S 
and give the new (compositional) clause for <S ds . Validate the well-definedness of 
the extended version of <Sds- 1=1 



To summarize, the well-definedness of <Sd S relies on the following results estab- 
lished above: 
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Proof Summary for While: 
Well-definedness of Denotational Semantics 



1: The set State State equipped with an appropriate order C is a ccpo 
(Lemmas 4.13 and 4.25). 

2: Certain functions VP: (State State) — > (State <^-> State) are contin- 
uous (Lemmas 4.43 and 4.45). 

3: In the definition of S^s we only apply the fixed point operation to contin- 
uous functions (Proposition 4.47). 



Properties of the semantics 

In the operational semantics we defined a notion of two statements being seman- 
tically equivalent. A similar notion can be defined based on the denotational 
semantics: Si and S2 are semantically equivalent if and only if 

<S ds [Si] = s da is 2 j 

Exercise 4.53 Show that the following statements of While are semantically 
equivalent in the above sense: 

• iS^skip and S 

• Si,(S 2 ;S 3 ) and (Si,S 2 );S 3 

• while b do S and if b then (S; while b do S) else skip □ 

Exercise 4.54 * Prove that repeat S until b and S; while ->b do S are seman- 
tically equivalent using the denotational approach. The semantics of the repeat- 
construct is given in Exercise 4.51. □ 



4.4 An equivalence result 

Having produced yet another semantics of the language While we shall be inter- 
ested in its relation to the operational semantics and for this we shall focus on the 
structural operational semantics. 



Theorem 4.55 For every statement S of While we have tSsosJiS 1 ] = <Sds[<Sl- 



4.4 An equivalence result 
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Both tSdsI^] and tSgosliS 1 ] are functions in State <^-> State, that is they are elements 
of a partially ordered set. To prove that two elements o?i and d 2 of a partially 
ordered set are equal it is sufficient to prove that c?i C d 2 and that d 2 C o?i. Thus 
to prove Theorem 4.55 we shall show that 

'-'SOS [5] C 5 ds [5], and 

• <Sds[^] E «WS]- 
The first result is expressed by the following lemma: 

Lemma 4.56 For every statement S of While we have tSsosI'?] Q S ds {S}. 

Proof: It is sufficient to prove that for all states s and s' 

(S, s) s' implies StelSjs = s' (*) 
To do so we shall need to establish the following property 

{S, s) s' implies <S d s[<S]<s = s ' 

{S, s) (S' : s') implies S ds {S}s = S ds [S']s' 

Assuming that (**) holds the proof of (*) is a straightforward induction on the 
length k of the derivation sequence {S, s) =^ k s' (see Section 2.2). 

We now turn to the proof of (**) and for this we shall use induction on the 
shape of the derivation tree for (S, s) =>• s' or (S, s) =>- (5", s'). 

The case [ass sos ]: We have 

(x := a, s) =>• s[a;i— hA[a]s] 

and since S ds {x '■= a}s — s[a;i— hAJaJs] the result follows. 
The case [skip sos ]: Analogous. 
The case [comp^J: Assume that 

(Si;S 2 , s) <5i;5 2 , s') 

because {Si, s) =>- {S[, s'). Then the induction hypothesis applied to the latter 
transition gives <5>dsl>>i] 5 = ^dsl^'i] 5 ' an d we get 

<5ds[5 i; 5 2 ] s = S ds lS 2 }(S ds lSi}s) 

= <5ds[5 2 ](5 ds [5' 1 ] S ') 

= S^S'^s' 

as required. 

The case [comp s 2 os ]: Assume that 
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{Si,S 2 , s) {S 2 , s') 

because {Si, s)=>- s'. Then the induction hypothesis applied to that transition 
gives <Sd S [<S'i]s — s ' an d we g et 

S^S^s = S ds lS 2 j{S ds lSijs) = S ds lS 2 ]s' 

where the first equality comes from the definition of <S ds and we just argued for 
the second equality. This proves the result. 

The case [if s " s ]: Assume that 

(if b then Si else S 2 , s) =>• {Si, s) 

because B{b} s = tt. Then 

<S ds [if b then Si else S 2 js = cond(B[6], 5ds[5i], 5ds[5 2 ])s = Sdsl^il 5 
as required. 

The case [if S o S ]: Analogous. 
The case [while sos ]: Assume that 

(while b do S, s) =>- (if b then (S; while b do S) else skip, s) 

From the definition of <S ds we have <S ds [while b do SJ — FIX F where F g = 
cond (£[&], g o S ds {SJ, id). We therefore get 

<S ds [while b do SJ= (FIX F) 

= F (FIX F) 

= cond(B[6], 5 ds [while b do SJ o S^SJ, id) 
= cond(B[6], S ds {S; while b do Sj, <S ds [skip]) 
= <S ds [if b then (S; while b do S) else skip] 

as required. This completes the proof of (**). □ 

Note that (*) does not imply that •SgosJiS'] = cMs^] as we have only proved 
that if S S0S {SJs 7^ undef then S S0S lSJs = S ds {SJs. Still there is the possibility that 
^SdsliS 1 ] may be defined for more arguments than <S SO s|['S , ]|- However this is ruled out 
by the following lemma: 



Lemma 4.57 For every statement S of While we have Sdsl^] Q «5bo B [5]. 



4.4 An equivalence result 
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Proof: We proceed by structural induction on the statement S. 

The case x :— a: Clearly Sdsl% '■— ajs — S sos {x :— ajs. Note that this means 
that <S B0B satisfies the clause defining S^s in Table 4.1. 

The case skip: Clearly <S ds [skip],s = <S S0S [skip]s. 

The case Si ; S 2 : Recall that o is monotone in both arguments (Lemma 4.45 and 
Exercise 4.46). We then have 

S ds {Si ; S 2 j = S da lS 2 j o S ds {Si} 

because the induction hypothesis applied to Si and S 2 gives <5d S [<S'i] C <5 S0S [iS'i] 
and tSdsI^] Q ^sosj^]- Furthermore, Exercise 2.21 gives that if {Si, s) s' 
then {Si ; 5*2, s) =>* {S 2 , s') and hence 

^sosl^] o ^sosj^i] C S^Si ; S 2 j 

and this proves the result. Note that in this case <S S0S fulfils a weaker version of 
the clause defining S d s in Table 4.1. 

The case if b then Si else S 2 : Recall that 'cond' is monotone in its second and 
third argument (Lemma 4.43 and Exercise 4.44). We then have 

<S ds [if b then Si else S 2 J = cond(B[6], <S ds [^i], <S ds [S 2 ]) 

C cond(B[6], S^], S S0S {S 2 }) 

because the induction hypothesis applied to Si and S 2 gives <5d S [<S'i] C tSsosI'S'i] 
and <5ds['5 , 2] Q S S0S IS 2 J. Furthermore, it follows from [if B " B ] and [if S o S ] that 

<S S0S [if b then Si else S 2 js = S S0S lSijs if B{bjs = tt 
<S S0S [if b then Si else S 2 js = S soa lS 2 }s if B{b}s = ff 

so that 

cond(£[6], 5 B0B [5i], 5bo B [5 2 ]) = <5 S0S [if b then Si else 5 2 ] 

and this proves the result. Note that in this case <S S0S fulfils the clause defining 
Sds in Table 4.1. 

The case while b do S: We have 

<S ds [while b do Sj = FIX F 

where F g = cond (#[&], g o <Sds||>>]j id) and we recall that F is continuous. It is 
sufficient to prove that 

F(S S0S [while 5 do 5]) C £ sos [while b do Sj 
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because then Exercise 4.40 gives FIX F C ^sosjwhile b do SJ as required. From 
Exercise 2.21 we get 

<S S0S [while b do S] = cond (#[&], (SsosI'S' ; while b do SJ, id) 

□ cond(B[6], <S S0S [while b do SJ o S S0S [S], id) 

The induction hypothesis applied to S gives <Sds[<Sl ^ ^sosI'S'] so using the mono- 
tonicity of o and 'cond' we get 

<S S0S [while b do SJ □ cond(£[6], <S S0S [while b do SJ o 5 B0B [5], id) 
□ cond(B[6], <S S0S [while 5 do 51 o S ds {Sj, id) 
= F(<S S0S [while b do 5]) 

Note that in this case S sos also fulfils a weaker version of the clause defining S^s 
in Table 4.1. □ 

The key technique used in the proof can be summarized as follows: 



Proof Summary for While: 
Equivalence of Operational Semantics and Denotational Semantics 



Prove that tSsosJ^] C <Sds[<Sl by first using induction on the shape of deriva- 
tion trees to show that 

• if a statement is executed one step in the structural operational 
semantics and does not terminate then this does not change the 
meaning in the denotational semantics, and 

• if a statement is executed one step in the structural operational 
semantics and does terminate, then the same result is obtained in 
the denotational semantics. 

and secondly by using induction on the length of derivation sequences. 
Prove that <Sds[<Sl Q <Ssos['Sl by showing that 

• <S S0S fulfils slightly weaker versions of the clauses defining <S ds in Table 
4.1, that is if 

= *(■■■ ■■■) 
then S S0S {S} □ *(---5 BM [5'] ■■■) 
A proof by structural induction then gives that <Sds[<Sl Q ^sosJiS 1 ]. 



4.5 Extensions of While 
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Exercise 4.58 Give a detailed argument showing that 

<S S0S [while b do Sj □ cond(B[6], <S S0S [while b do Sj o S S0S [S], id). □ 

Exercise 4.59 Extend the proof of Theorem 4.55 so that it applies to the language 
when augmented with repeat S until b. □ 

Exercise 4.60 Extend the proof of Theorem 4.55 so that it applies to the language 
when augmented with for x: — a\ to a 2 do S. □ 

Exercise 4.61 Combining the results of Theorem 2.26 and Theorem 4.55 we get 
that <Sns[<Sl — <Sds[<Sl holds for every statement S of While. Give a direct proof 
of this (that is without using the two theorems). □ 

4.5 Extensions of While 

We shall conclude this chapter by considering a couple of extensions of the language 
While. The extensions have been chosen so as to illustrate two of the most 
important concepts of denotational semantics: 

• locations, and 

• continuations. 

In the first case While is extended with blocks and procedures and in the second 
case with exceptions. In both cases we shall show how to modify the semantics of 
Table 4.1. 

The concept of locations 

We shall first extend While with blocks declaring local variables and procedures. 
The new language is called Proc and its syntax is 

S ::= x := a skip \ Si ; S2 | if b then Si else S2 

while b do S begin Dy Dp S end | call p 

Dy ::— var x := a; Dy \ e 

Dp ::— proc p is S; Dp | e 

where Dy and D P are meta-variables ranging over the syntactic categories Dec v 
of variable declarations and Dec P of procedure declarations, respectively, and p is 
a meta-variable ranging over the syntactic category Pname of procedure names. 
The idea is that variables and procedures are only known inside the block where 
they are declared. Procedures may or may not be recursive and we shall emphasize 
the differences in the semantics to be specified below. 

We shall adopt static scope rules rather than dynamic scope rules. Consider 
the following statement: 
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begin var x := 7; proc p is x :— 0; 
begin var x := 5; call p end 

end 

Using static scope rules the effect of executing call p in the inner block will be 
to modify the global variable x. Using dynamic scope rules the effect will be to 
modify the local variable x. 

To obtain static scope rules we shall introduce the notion of locations: to 
each variable we associate a unique location and to each location we associate a 
value. This is in contrast to what we did in Table 4.1 where we employed a direct 
association between variables and values. The idea then is that whenever a new 
variable is declared it is associated with a new unused location and that it is the 
value of this location that is changed by assignment to the variable. With respect 
to the above statement this means that the global variable x and the local variable 
x will have different locations. In the inner block we can only directly access the 
location of the local variable but the procedure body for p may only access the 
location of the global variable. 

Stores and variable environments 

So far states in State have been used to associate values with variables. We shall 
now replace states with stores that map locations to values and with variable 
environments that map variables to locations. We introduce the domain 

Loc = Z 

of locations which for the sake of simplicity has been identified with the integers. 
We shall need an operation 

new: Loc — > Loc 

on locations that given a location will give the next one; since Loc is Z we may 
take 'new' to be the successor function on the integers. 
We can now define a store, sto, as an element of 

Store = Loc U {next} — > Z 

where 'next' is a special token used to hold the next free location. Note that since 
Loc is Z we have that 'sto next' is a location. 
A variable environment envy is an element of 

Envy = Var — > Loc 

Thus the variable environment will assign a location to each variable. 

So, rather than having a single mapping s from variables to values we have 
split it into two mappings envy and sto and the idea is that s = sto o envy. This 
motivates defining the function 'lookup' by 
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\x: — a\envy sto — sto\l^-A\a\ (lookup envy sto)] 




where / = envy x 




[skipjenvy = id 


us 


\Si ; S2\env v — (S' d JS2\envy) o (SLlSAenvy) 


^ds 


n *F h 1"Vipn R -\ pi rp R ptid^t — 




cond (B{ b] o (lookup env v ), S' ds lSi}envy, S' ds lS2}envy) 


S'ds 


[while b do Sjenvy = FIX F 




where F g — cond (£[ 6] o (lookup envy), # o (^gJiS'Jenwy), id) 



Table 4.2: Denotational semantics for While using locations 



lookup envy sto — sto o envy 

so that 'lookup envy' will transform a store to a state, that is 

lookup: Envy — > Store — > State 

Having replaced a one stage mapping with a two stage mapping we shall want 
to reformulate the semantic equations of Table 4.1 to use variable environments 
and stores. The new semantic function S' ds has functionality 

S' ds : Stm — > Envy — > (Store Store) 

so that only the store is updated during the execution of statements. The clauses 
defining S' ds are given in Table 4.2. Note that in the clause for assignment the 
variable environment is consulted to determine the location of the variable and 
this location is updated in the store. In the clauses for the conditional and the 
while-construct we use the auxiliary function 'cond' of functionality 

cond: (Store -> T) x (Store <^-> Store) x (Store <^-> Store) 
— > (Store <^-> Store) 

and its definition is as in Section 4.1. 

Exercise 4.62 We have to make sure that the clauses of Table 4.2 define a well- 
defined function S' ds . To do so 

• equip Store <^-> Store with a partial ordering such that it becomes a ccpo, 

• show that o is continuous in both of its arguments and that 'cond' is contin- 
uous in its second and third argument, and 
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• show that the fixed point operation is only applied to continuous functions. 
Conclude that S' ds is a well-defined function. □ 

Exercise 4.63 * Prove that the two semantic functions S^s and S' ds satisfy 

£ds[<Sl ° (lookup env v ) — (lookup env v ) ° (<Sd S [<S , ]en?;y) 

for all statements 5* of While and for all envy such that envy is an injective 
mapping. □ 

Exercise 4.64 Having replaced a one stage mapping with a two stage mapping we 
might consider redefining the semantic functions A and B. The new functionalities 
of A and B might be 

A': Aexp -> Env v -> (Store -> Z) 
B'\ Bexp ->■ Env v ->■ (Store ->■ T) 

and the intended relationship is that 

^4'JaJenvy = «4|a] o (lookup envy) 
B'[6]enwy = B\b\ o (lookup envy) 

Give a compositional definition of the functions A' and B' such that this is the 
case. □ 



Updating the variable environment 

The variable environment is updated whenever we enter a block containing local 
declarations. To express this we shall introduce a semantic function X?^ for the 
syntactic category of variable declarations. It has functionality 

V ds : Dec v — > Envy x Store — > Envy x Store 

The function X'XslI-^V] W1 H take a pair as arguments: the first component of that 
pair will be the current variable environment and the second component the current 
store. The function will return the updated variable environment as well as the 
updated store. The function is defined by the semantic clauses of Table 4.3. Note 
that we process the declarations from left to right and that we update the value 
of the token 'next' in the store. 

In the case where there are no procedure declarations in a block we can extend 
the semantic function S' ds of Table 4.2 with a clause like 

S' ds [begin Dy S end] envy sto — S' ds lS} env'y sto' 
where V ds lD v J(envy, sto) — (env' v , sto') 



4.5 Extensions of While 



121 



X>^ s [var x :— a; D v }(env v , sto) = 

Vj s {D v J(envv[x>-^l], sto[l\- )-u][nexti— mew /]) 
where / = sto next and v = A{aJ (lookup envy sto) 

VJM = id 

Table 4.3: Denotational semantics for variable declarations 

Thus we evaluate the body S in an updated variable environment and an updated 
store. We shall later modify the above clause to take the procedure declarations 
into account. 

Exercise 4.65 Consider the following statement of Proc: 

begin var y := 0; var x := 1; 

begin var x := 7; x := x+1 end; 
y := x 

end 

Use the semantic equations to show that the location for y is assigned the value 1 
in the final store. □ 

Procedure environments 

To cater for procedures we shall introduce the notion of a procedure environment. 
It will be a total function that will associate each procedure with the effect of 
executing its body. This means that a procedure environment, envp, will be an 
element of 

Envp = Pname — > (Store <^-> Store) 

Remark This notion of procedure environment differs from that of the operational 
approach. □ 
The procedure environment is updated using the semantic function V^ s for 
procedure declarations. It has functionality 

V^ s : Deep — > Env v — > Env P — > Env P 

So given the current variable environment and the current procedure environment 
the function ^dsl-^^l w ^ update the procedure environment. The variable envi- 
ronment must be available because procedures must know the variables that have 
been declared so far. An example is the statement 
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^ds[P roc P is 


S 


Dp]env v env P = V^lDpjenvv (envp[p\->g]) 


where g 




SdsfSJ env v env P 


V^lejenvy = 


id 





Table 4.4: Denotational semantics for non-recursive procedure declarations 



begin var x := 7; proc p is x := 0; 
begin var x := 5; call p end 

end 

where the body of p must know that a variable x has been declared in the outer 
block. 

The semantic clauses defining T)\\ in the case of non-recursive procedures are 
given in Table 4.4. In the clause for procedure declarations we use the semantic 
function S^s for statements (defined below) to determine the meaning of the body 
of the procedure using that envy and envp are the environments at the point of 
declaration. The variables occurring in the body S of p will therefore be bound to 
the locations of the variables as known at the time of declaration but the values 
of the locations will not be known until the time of call. In this way we ensure 
that we obtain static scope for variables. Also an occurrence of call p' in the 
body of the procedure will refer to a procedure p' mentioned in envp, that is a 
procedure declared in an outer block or in the current block but preceding the 
present procedure. In this way we obtain static scope for procedures. This will be 
illustrated in Exercise 4.67 below. 

The semantic function Sa s for Proc 

The meaning of a statement depends on the variables and procedures that have 
been declared. Therefore the semantic function S^s for statements in Proc will 
have functionality 

S ds : Stm -> Env v -> Env P -> (Store Store) 

The function is defined by the clauses of Table 4.5. In most cases the definition of 
is a straightforward modification of the clauses of S' ds . Note that the meaning 
of a procedure call is obtained by simply consulting the procedure environment. 

Example 4.66 This example shows how we obtain static scope rules for the vari- 
ables. Consider the application of the semantic function <S ds to the statement 

begin var x := 7; proc p is x := 0; 

begin var x := 5; call p end 

end 
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S,x s \x: — a\envy envp sto — sto[l^A{ a] (lookup envy 


sto)] 


where / = envy x 




<Sd S [skip] envy envp = id 




<Sdslf<S'i ; Solenvy envp — (SdslSolenvy envp) o (Sds 


ISA envy envp) 


Nif /) then Sli elss Snll pniisr pnvo = 




condfRlffolloflookun pnv-tA SA B \S-\\&nv\f cni)r> 




SfalS-Aenvv envp) 




5d S [while 6 do tSJenvy enwp = FIX F 




where F g = cond(£[ 6] o (lookup envy), 




g o (S ds {Sjenv v env P ), id) 




<Sd S [begin D v Dp S end] envy envp sto = SdslS}env' v env' P sto' 


where Vj s lD v J(envy, sto) — (env' v , sto') 




and V^ s lD pjenv' v envp — env' P 




«5d S [call pjenvy envp = envp p 





Table 4.5: Denotational semantics for Proc 



Assume that the initial environments are envy and envp and that the initial 
store sto has sto next = 12. Then the first step will be to update the variable 
environment with the declarations of the outer block: 

V dA v3ir x : = 7 'M env v, sto) 

= V dA £ }( env v[x^l2], sfo[12M>7][nextM>13]) 
= (env v [x^l2], s*o[12i-»7][nexti-»13]) 

Next we update the procedure environment: 

D^Jproc p is x := 0;] (envy [xi— >-12]) envp 
= V^[e](env v [x^l2]) (env P [ V ^g]) 
= env P \pi-+g] 

where 



g sto — Sdsl x '■— 0] (envy [xi->12]) envp sto 
= sfo[12^0] 
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because x is to be found in location 12 according to the variable environment. 
Then we get 

<Sds[begin var x := 7; proc p is x := 0; 

begin var x := 5; call p end endjenvy envp sto 

— <5ds[b e gi n var x := 5; call p end] (enwy[xi— >-12]) (enwp[pi— >g]) 

(s£o[12i->-7][nexti->-13]) 

For the variable declarations of the inner block we have 

Vjjvar x := 5;j(env v [»-»12], afo[12i-»7][nexti-»13]) 

= V dA4( env v[x^l3], sto [12^-7] [13^-5] [nextM- 14]) 

= (env v [xh^l3], sfo[12i->7][13i->5][nexti->14]) 

and 

^H( er »M xh ^ 13 ]) (env P \pi-+g]) = env P \p^g] 
Thus we get 

<Sds[begin var x 5; call p end] [envy [xh->-12]) (enwp[pi— >g\) 

(s£o[12i->-7][nexti->-13]) 
= <S ds [call p](enw y [xi-)-13]) (env P [ph^g]) 

(s£o[12^7][13^5][next^l4]) 

= g (afo[12i-»7][13i-»5][nexti-»14]) 

= s£o[12^0][13^5][next^l4] 

so we see that in the final store the location for the local variable has the value 5 
and the one for the global variable has the value 0. □ 

Exercise 4.67 Consider the following statement in Proc: 

begin var x := 0; 

proc p is x := x+1; 

proc q is call p; 

begin proc p is x := 7; 

call q 

end 

end 

Use the semantic clauses of Proc to illustrate that procedures have static scope, 
that is show that the final store will associate the location of x with the value 1 
(rather than 7). □ 
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D^fproc p is S; D P ]env v env P = V^ s lD P ]env v (env P [p^FlX F\) 
where F g — S& S \S\ envy (envp\p\-tg]) 

Z>a,[e]enuy = id 

Table 4.6: Denotational semantics for recursive procedure declarations 

Recursive procedures 

In the case where procedures are allowed to be recursive we shall be interested in 
a function g in Store <^-> Store satisfying 

g = S ds {Sj env v (env P [p^g\) 

since this will ensure that the meaning of all the recursive calls is the same as that 
of the procedure being defined. For this only the clause for X^Jproc p is S; D P \ 
needs to be modified and the new clause is given in Table 4.6. We shall see in 
Exercise 4.69 that this is a permissible definition, that is F of Table 4.6 is indeed 
continuous. 

Remark Let us briefly compare the above semantics with the operational seman- 
tics given in Section 2.5 for the same language. In the operational semantics the 
possibility of recursion is handled by updating the environment each time the pro- 
cedure is called and, except for recording the declaration, no action takes place 
when the procedure is declared. In the denotational approach, the situation is very 
different. The possibility of recursion is handled once and for all, namely when 
the procedure is declared. □ 

Exercise 4.68 Consider the declaration of the factorial procedure 
proc fac is begin var z := x; 

if x = 1 then skip 

else (x := x — 1; call fac; y := z * y) 

end; 

Assume that the initial environments are envy and env P and that envy x = l x 
and envy y = l y . Determine the updated procedure environment. □ 

As for While we must ensure that the semantic clauses define a total function 
Sds- We leave the details to the exercise below. 

Exercise 4.69 ** To ensure that the clauses for S^s define a total function we 
must show that FIX is only applied to continuous functions. In the case of recursive 
procedures this is a rather laborious task. First one may use structural induction 
to show that Vj s is indeed a well-defined function. Secondly one may define 
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envp C' env' P if and only if envp p C env P p for all p 6 Pname 

and show that (Envp, C') is a ccpo. Finally, one may use Exercise 4.41 (with D 
being Store Store) to show that for all envy £ Envy the clauses of Tables 
4.3, 4.5 and 4.6 do define continuous functions 

5d S [5']enwy: Envp — > (Store Store) 
I>j s [Z?p]enuy: Env P -> Env P 

This is performed using mutual structural induction on statements S and decla- 
rations Dp. □ 

Exercise 4.70 Modify the syntax of procedures so that they take two call-by- 
value parameters: 

Dp ::= proc p(x 1 ,x 2 ) is S; D P \ e 
S ::= ■ ■ ■ | call p(a 1 ,a 2 ) 

The meaning of a procedure will now depend upon the values of its parameters 
as well as the state in which it is executed. We therefore change the definition of 
Envp to be 

Envp = Pname -> ((Z x Z) -> (Store <^-> Store)) 

so that given a pair of values and a store we can determine the final store. Modify 
the definition of S^s to use this procedure environment. Also provide semantic 
clauses for V^ s in the case of non-recursive as well as recursive procedures. Con- 
struct statements that illustrate how the new clauses are used. □ 

Exercise 4.71 * Modify the semantics of Proc so that dynamic scope rules are 
employed for variables as well as procedures. □ 

The concept of continuations 

Another important concept from denotational semantics is that of continuations. 
To illustrate it we shall consider an extension of While where exceptions can be 
raised and handled. The new language is called Exc and its syntax is: 

S ::— x := a | skip | S\ ; S 2 \ if b then 5"i else S 2 

while b do S | begin Si handle e: S 2 end | raise e 

The meta-variable e ranges over the syntactic category Exception of exceptions. 
The statement raise e is a kind of jump instruction: when it is encountered, the 
execution of the encapsulating block is stopped and the flow of control is given to 
the statement declaring the exception e. An example is the statement 
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begin while true do if x<0 

then raise exit 
else x := x— 1 
handle exit: y :— 7 

end 

Assume that so is the initial state and that so x > 0. Then the false branch of the 
conditional will be chosen and the value of x decremented. Eventually, x gets the 
value and the true branch of the conditional will raise the exception exit. This 
will cause the execution of the while-loop to be terminated and control will be 
transferred to the handler for exit. Thus the statement will terminate in a state 
where x has the value and y the value 7. 

The meaning of an exception will be the effect of executing the remainder of 
the program starting from the handler. Consider a statement of the form 

(if b then Si else S 2 ) ; S3 

In the language While it is evident that independently of whether we execute 
Si or 52 we have to continue with S3. When we introduce exceptions this does 
not hold any longer: if one of the branches raises an exception not handled inside 
that branch, then we will certainly not execute S3. It is therefore necessary to 
rewrite the semantics of While to make the "effect of executing the remainder of 
the program" more explicit. 

Continuation style semantics for While 

In a continuation style semantics the continuations describe the effect of executing 
the remainder of the program. For us a continuation c is an element of the domain 

Cont = State ^ State 

and is thus a partial function from State to State. Sometimes one uses partial 
functions from State to a "simpler" set Ans of answers but in all cases the purpose 
of a continuation is to express the "outcome" of the remainder of the program when 
started in a given state. 

Consider a statement of the form ■ ■ ■; S ; ■ ■ ■ and let us explain the meaning of 
S in terms of the effect of executing the remainder of the program. The starting 
point will be the continuation c determining the effect of executing the part of 
the program after S, that is c s is the state obtained when the remainder of the 
program is executed from state s. We shall then determine the effect of executing 
S and the remainder of the program, that is we shall determine a continuation c! 
such that c' s is the state obtained when executing S and the part of the program 
following S from state s. Pictorially, from 
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S' cs lx:=a}c s = c (s[x^A[a\s\) 
^[skip] = id 

S' CS {S 1 ; S 2 j = S'^IS,} o S' a [S 2 ] 

S' cs {if b then S, else S 2 jc = cond(B[6], S'^SJc, S' cs lS 2 jc) 

S^Jwhile b do Sj = FIX G 

where (g g) c = condgM, g^gKff c), c) 

Table 4.7: Continuation style semantics for While 



c 

we want to obtain 

••• ; S ; 

» ' 

c' 

We shall define a semantic function <S^. S for While that achieves this. It has 
functionality 

S' ca : Stm ->■ (Cont ->■ Cont) 

and is defined in Table 4.7. The clauses for assignment and skip are straightfor- 
ward; however, note that we now use id as the identity function on Cont, that is 
id c s — c s. In the clause for composition the order of the functional composition 
is reversed compared with the direct style semantics of Table 4.1. Intuitively, the 
reason is that the continuations are "pulled backwards" through the two state- 
ments. So assuming that c is the continuation for the remainder of the program 
we shall first determine a continuation for S 2 followed by the remainder of the 
program and next for Si followed by S 2 and the remainder of the program. 

The clause for the conditional is straightforward as the continuation applies 
to both branches. In the clause for the while-construct we use the fixed point 
operator as in the direct style semantics. If the test of while b do S evaluates to 
ff then we return the continuation c for the remainder of the program. If the test 
evaluates to tt then g c denotes the effect of executing the remainder of the loop 
followed by the remainder of the program and is the continuation to be used for 
the first unfolding of the loop. 

Example 4.72 Consider the statement z := x; x := y; y := z of Chapter 1. Let 
id be the identity function on State. Then we have 
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S'cJz ■= x := y; y := z]id 

= (S'Jz := x] o S'Jx := y] o S' C J Y := z]) id 
= (^ s [z := x] o ^ s [x := y]) 9l 

where gi s — id(s[yi— >-(s z)]) 
= S'Jz := xfo 2 

where g 2 s = g 1 (s[x^(s y)]) 

= id(s[x^(s y)][y^(s z)]) 

= 9s 

where g 3 s = g 2 (s[z\-^(s x)]) 

= id(s[z^( s x)][x4(« y)][y^-(s x)]) 

Note that the semantic function is constructed in a "backwards" manner. □ 

As in the case of the direct style semantics we must ensure that the semantic 
clauses define a total function S' cs . We leave the details to the exercise below. 

Exercise 4.73 ** To ensure that the clauses for S' cs define a total function we 
must show that FIX is only applied to continuous functions. First one may define 

<?i Q' <?2 if and only if gi c C g 2 c for all c 6 Cont 

and show that (Cont — >- Cont, C') is a ccpo. Secondly, one may define 

[Cont — > Cont] = { g: Cont — > Cont | g is continuous } 

and show that ([Cont — > Cont], C') is a ccpo. Finally, one may use Exercise 4.41 
(with D — [Cont — > Cont]) to show that the clauses of Table 4.7 define a function 

S' cs : [Cont ->■ Cont] 

using structural induction on S. □ 

Exercise 4.74 * Prove that the two semantic functions S^s and S' cs satisfy 

S' cs lSjc = c o S ds {Sl 
for all statements S of While and for all continuations c. □ 



Exercise 4.75 Extend the language While with the construct repeat S until b 

and give the new (compositional) clause for S' cs . □ 
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S cs \x:—a\env E c s — c hAJaJs]) 
5 cs [skip]enw£; = id 

^csl^i ; S 2 jenv E = (S cs lS!}env E ) o (S CB [S 2 ]env E ) 
S cs {if b then Si else ^Jem^ c = 

cond (#[&], ScslSijenvE c, 5 CB [5 2 ]eni; f ; c) 
<S cs [while b do SJenvE = FIX G 

where (G g) c = cond(#[6], 5 cs [5]enu£; (5 c), c) 
<S CS [begin 5i handle e: endjenw^ c = 

^csJS'iKenUisfei-^^csl^lenUis c]) c 

<S cs [raise ejenw^ c = env E e 

Table 4.8: Continuation style semantics for Exc 

The semantic function <S CS for Exc 

In order to keep track of the exceptions that have been introduced we shall use an 
exception environment. It will be an element, env E , of 

EnvE = Exception — > Cont 

Given an exception environment env E and an exception e, the effect of executing 
the remainder of the program starting from the handler for e will then be env E e. 

The semantic function S cs for the statements of the language Exc has func- 
tionality 

S cs : Stm -> Env E -> (Cont -> Cont) 

The function is defined by the clauses of Table 4.8. Most of the clauses are straight- 
forward extensions of those given for While in Table 4.7. The meaning of the block 
construct is to execute the body in the updated environment. Therefore the envi- 
ronment is updated so that e is bound to the effect of executing the remainder of 
the program starting from the handler for e and this is the continuation obtained 
by executing first ^2 and then the remainder of the program, that is S cs \S2ienv E 
c. Finally, in the clause for raise e we ignore the continuation that is otherwise 
supplied. So rather than using c we choose to use env E e. 

Example 4.76 Let env E be an initial environment and assume that the initial 
continuation is the identity function, id. Then we have 
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<S cs [begin while true do if x<0 then raise exit else x := x— 1 

handle exit: y := 7 endjenv^ id 
= (FIX G) id 

where G is defined by 

G g c s — cond(#[true], 

cond(#[x<0], Cexit, S cs {x := x-l]enu£;[exiti-4-c exit ] (g c)), 
c) s 

Cexit S if S X < 

(g c) (s[xi->(s x)-l]) if 5 x > 

and the continuation c ex it associated with the exception exit is given by 

Cexit s = id (a[yi-»7]) = a[y^7] 

Note that G may choose to use the "default" continuation c or the continuation 
Cexit associated with the exception, as appropriate. We then get 

f s[y^7l if s x < 

(FIX G) id s = < ~ □ 

{ s[x^0][y^7] if s x > 

Exercise 4.77 Show that FIX G as specified in the above example is indeed the 
least fixed point, that is construct the iterands G n _L and show that their least 
upper bound is as specified. □ 

Exercise 4.78 ** Extend Exercise 4.73 to show the well-definedness of the func- 
tion S cs defined by the clauses of Table 4.8. □ 

Exercise 4.79 Suppose that there is a distinguished output variable out 6 Var 
and that only the final value of this variable is of interest. This might motivate 
defining 

Cont = State «^ Z 

Define the initial continuation cq £ Cont. What changes to Env E , the function- 
ality of S cs and Table 4.8 are necessary? □ 
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Chapter 5 

Static Program Analysis 



When implementing a programming language it is crucial that the implementa- 
tion is faithful to the semantics of the language and in Chapter 3 we saw how the 
operational semantics could be used to prove this formally. However, it is also im- 
portant that the implementation is reasonably efficient and it is therefore common 
to combine the code generation with various analyses collecting information about 
the programs. In this chapter we shall develop one such analysis in detail but let 
us first consider a couple of example analyses. 

Constant propagation is an analysis that determines whether an expression 
always evaluates to a constant value and if so determines that value. The analysis 
is the basis for an optimization called constant folding where the expression is 
replaced by the constant. As an example the analysis will detect that the value of 
y in the statement 

x := 5; y := x * x + 25 

will always be 50. It is therefore safe to replace the statement by 

x := 5; y := 50 

and more efficient code can be generated. 

Another example is the detection of signs analysis where the idea is to deter- 
mine the sign of expressions. So it will for example determine that the value of y 
in 

y := x * x + 25 

always will be positive (independently of the value assigned to x). This information 
will be useful for an optimization known as code elimination: in a statement as 

y := x * x + 25; while y < do • • • 
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there is no need to generate code for the while-loop because it will never be 
executed. 

The example analysis to be developed in this chapter is a dependency analysis. 
Here the idea is to regard some of the variables as input variables and others as 
output variables. The analysis will then determine whether or not the final values 
of the output variables only depend upon the initial values of the input variables. If 
so we shall say that there is a functional dependency between the input and output 
variables of the statement. As an example consider once more the statement 

y := x * x + 25 

and assume that x is an input variable and y an output variable. Then the analysis 
will conclude that there is indeed a functional dependency between the input and 
output variables for the above statement. However, if x is not an input variable 
then the analysis will determine that the value of y is dubious as it does not solely 
depend on the values of the input variables. In that case the compiler might choose 
to issue a warning as this probably is not the intention of the programmer. 
A more interesting example program is the factorial statement: 

y := 1; while -i (x = 1) do (y := y * x; x := x — 1) 

Again assume that x is an input variable and that y is an output variable. Then 
the final value of y only depends upon the initial value of x. However, if we drop 
the initialization of y (and assume that y is not an input variable) and consider 
the statement 

while -i (x = 1) do (y := y * x; x := x — 1) 

then the final value of y does not only depend on the initial value of the input 
variable x, but also on the initial value of y, so it is not the case that the final values 
of the output variables only depend on the initial values of the input variables. 

The kind of analyses exemplified above can be specified by defining so-called 
non-standard semantics of the programming language. These semantics will be 
patterned after the denotational semantics of Chapter 4 but they differ in that 
they do not operate on the exact values of variables and expressions but rather on 
properties of the exact values. For the constant propagation analysis we may use 
properties like 

ANY, CONST-0, CONST-1, CONST-2, • • • 

For the detection of signs analysis we may use properties like 

ANY, POS, NEG, and ZERO 

and for the dependency analysis we may use properties 
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D? (meaning dubious) and OK (meaning proper) 

Usually, the analyses will be part of a compiler and it is therefore important 
that they always terminate even for programs that loop when executed. The price 
we pay for always getting answers is that we occasionally get imprecise answers. So 
in the case of constant propagation the property any means that the analysis was 
not able to detect that the value always would be constant. Similarly, the property 
any for the detection of signs analysis means that the analysis was not able to 
detect a unique sign for the value. For the dependency analysis the property D? 
means that the analysis was not able to detect that the value only depends on 
the input variables. Note that an analysis that always returns these "fail-safe" 
properties will be a safe analysis although not a very informative one. Also note 
that in the case of the dependency analysis we could always expect the answer ok 
if all variables were regarded as input variables but again this is not what we are 
interested in. 

The analysis we shall develop will detect whether or not a statement definitely 
has a functional dependency between its input and output variables. The overall 
algorithm operates as follows: initially all input variables have the property OK 
and all other variables the property D?. Then the analysis is performed and when 
it has terminated the properties of the output variables are inspected. If they are 
all OK then the analysis returns the answer YES and otherwise NO?. The analysis 
is guaranteed to give an answer within a finite amount of time (depending upon 
the statement) but the answer will not be precise in all cases. However, it will 
always be safe in the sense that 

• if the analysis says YES then there is indeed a functional dependency between 
input and output, but 

• if the analysis says NO? then there may or may not be a functional depen- 
dency between input and output. 

The analysis will be specified compositionally just as the denotational semantics of 
Chapter 4. As mentioned above the main difference between the analysis and the 
denotational semantics is that the analysis does not operate on exact values but 
rather on properties of exact values. Because of the close correspondence between 
the specification of the analysis and the denotational semantics we shall prove the 
safety of the analysis with respect to the denotational semantics. 

5.1 Properties and property states 

For the dependency analysis we shall be interested in two properties: 

• ok meaning that the value definitely only depends on the initial values of 
the input variables, and 
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• D? meaning that the value may depend on the initial values of non-input 
variables, that is the value may be dubious. 

We shall write 

P = {ok, d?} 

for this set of properties and we use p as a meta- variable ranging over P. It is 
more informative to know that an expression has the property OK than D?. As a 
record of this we define a partial order C P on P: 

OK C P D?, OK C P OK, D? C P D? 

and depicted as 

• D? 

• OK 

Thus the more informative property is at the bottom of the ordering! We have 



Fact 5.1 (P, Cp) is a complete lattice. If Y is a subset of P then 
Up Y = D? if and only if D? £ Y 



Proof: The proof is straightforward using the definition of complete lattices given 
in Chapter 4. □ 

It is convenient to write pi U P j) 2 instead of Up{Pi, ^2}- It follows from Fact 
5.1 that the binary operation U P may be given by the table 



Up 


OK 


D? 


OK 


OK 


D? 


D? 


D? 


D? 



When reasoning about the safety of the analysis we need to be a bit more precise 
about the meaning of the properties with respect to the values of the denotational 
semantics. While it may be intuitively clear whether or not the value of a variable 
only depends on the input variables, it turns out to be impossible to inspect a 
specific value, for example 27, and decide whether or not this is indeed the case. 
The reason is that we lose the context in which the value arises. We shall solve 
this difficulty in Section 5.3 and to prepare for the solution we shall define the 
following parameterized relations: 

relA exp : P^fZxZ^T) 

rel B ex P : P (T x T T) 
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For arithmetic expressions the relation is defined by: 

{tt p — D? or vi — v 2 
if otherwise 

and similarly for boolean expression: 

tt p — D? or Vi — v 2 



ielBexp(p)(«i, v 2 ) = 



ff otherwise 



We shall often omit the subscript when no confusion is likely to result. Each 
of the relations take a property and two values as parameters. Intuitively, the 
property expresses how much the two values are allowed to differ. Thus D? puts 
no requirements on the values whereas OK requires that the two values are equal. 
As an aid to readability we shall often write 

Vi = v 2 rel p 

instead of rel(p)(w 1 , v 2 ) and we shall say that v\ and v 2 are equal as far as p is 
concerned (or relative to p). 



Property states 

In the operational and denotational semantics a state maps variables to their 
values. In the analysis the counterpart of this will be a property state which maps 
variables to properties, that is essentially a function in Var — > P. The idea is that 
the initial property state will only map the input variables to OK and that if the 
final property state is acceptable and maps all output variables to OK then the 
output of the statement will definitely be functionally dependent on the input. 

To make this idea work we have to extend the property state to model one 
additional phenomenon, namely the "flow of control" . We shall illustrate this in 
Example 5.3 below but let us first introduce some notation that will handle the 
problem. The set P State of property states ranged over by the meta- variable ps, 
is defined by 

PState = (Var U {on-track}) ->■ P 

where 'on-track' is a special token used to model the "flow of control" . If 'on-track' 
is mapped to OK this means that the "flow of control" only depends upon the 
values of the input variables; if it is mapped to D? this need not be the case. For 
a property state ps E PState we define the set 

OK (ps) — { x £ Var U {on-track} | ps x — OK } 

of "variables" mapped to OK and we say that 



138 



5 Static Program Analysis 



ps is proper if and only if (on-track) = OK. 

If ps is not proper we shall sometimes say that it is improper. 

The relationship between property states and states is given by the parameter- 
ized relation: 

rel stm : PState ->■ (State x State ->■ T) 

defined by 



and again we may omit the subscript when no confusion is likely to occur. The 
relation expresses the extent to which two states are allowed to differ as far as a 
given property state is concerned. If ps is not proper then rel(ps) will hold on any 
two states. However, if ps is proper then re\(ps) will hold on two states if they are 
equal on the variables in OK(ps). Phrased differently, we may view ps as a pair 
of glasses that only allows us to see part of the states and rel(ps)(si, s 2 ) means 
that si and s 2 look the same when viewed through that pair of glasses. Again we 
shall write 

Si = s 2 rel ps 

for rel(ps)(si, s 2 ). 

Example 5.2 Let si, s 2 and ps be given by 

Si x = 1 and si y = for y E Var\{x} 
s 2 x = 2 and s 2 y — for y e Var\{x} 
ps x — D? and ps y — OK for y 6 (Var U {on-track})\{x} 

Then si = s 2 rel ps. □ 

Example 5.3 To motivate the need for improper property states, that is the need 
for 'on-track', consider the following statements: 

Si: x := 1 
S 2 : x := 2 

It would be natural to expect that the analysis of Si will map any property state 
ps to the property state ps[x\- >ok] since a constant value cannot depend on the 
value of any (non-input) variable. A similar argument holds for S 2 . Now consider 
the statements 



r tt 



if ps on-track = D? 

or V x 6 Var n OK(ps): Si x — s 2 x 



rel st m(ps)(si, s 2 ) 



— < 



ff 



otherwise 
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Si±: if x = 1 then else 
Si 2 : if x = 1 then else S 2 

Again we may expect that the analysis of Sn will map any property state ps to 
the property state ps[x\- >Ok], since Sn is semantically equivalent to Si. 

Concerning S 12 it will not always be correct for the analysis to map a property 
state ps to ps[x\- >ok]. For an example suppose that ps, Si and s 2 are such that 

ps x — D? and ps y — OK for y 6 (Var U {on-track})\{x} 
si x = 1 and si y — for y 6 Var\{x} 
s 2 x — 2 and s 2 y = for y e Var\{x} 
Then Example 5.2 gives 
-Si = s 2 rel ps 

but <Sds['S , i2]<Si = <5d S [<S , i 2 ]s 2 rel ps[xM-OK] fails because <Sds||>>i2]<Si = Si and 
<5 ds [5 , i2]5 2 = s 2 and si x ^ s 2 x. 

However, from the point of view of the analysis there is no difference between 
Si and 152 because neither the value of 1 nor 2 depends on the values of the input 
variables. Since the analysis is compositionally defined this means that there 
can be no difference between Sn and ^12 from the point of view of the analysis. 
Therefore we have to accept that also the analysis of Sn should not allow mapping 
an arbitrary property state ps to ps[xi— >-Ok]. 

The difference between Si and S 2 arises when the "flow of control" does not 
depend on the input variables and it is here the need for the special token 'on-track' 
comes in. We shall transform a property state into an improper one, by mapping 
'on-track' to D?, whenever the "flow of control" is not "functionally dependent" 
on the input variables. Thus if ps x — D? then it is the test, x = 1, in Sn 
and 1512 that will be responsible for mapping ps into the improper property state 
ps [on-tracki— »D?] and then the effect of analysing Si and S 2 does not matter as 
long as an improper property state is not mapped into a proper one. □ 

Our next task will be to endow PState with some partially ordered structure 
and to investigate the properties of rel Stm . Concerning the former this will be an 
instance of a general procedure: 



Lemma 5.4 Assume that S is a non-empty set and that (D, C) is a partially 
ordered set. Let C' be the ordering on the set S^D defined by 

/1 Q' /2 if and only iifix\Zf 2 x for all x 6 S 

Then (S—>D, C') is a partially ordered set. Furthermore, (S—tD, C') is a ccpo if 
D is and it is a complete lattice if D is. In both cases we have 



140 



5 Static Program Analysis 



(U'Y)x = U{f x\f E Y } 
so that least upper bounds are determined pointwise. 



Proof: It is straightforward to verify that C' is a partial order so we omit the 
details. We shall first prove the lemma in the case where D is a complete lattice 
so let Y be a subset of S — > D. Then the formula 

(UY)x = U{f x\f e Y } 

defines an element |J' Y of S — > D because D being a complete lattice means that 
U{ / x I / G Y } exists for all x of S. This shows that \JY is a well-defined 
element of S — > D. To see that \J'Y is an upper bound of Y let / G Y and we 
shall show that /o Q' \JY . This amounts to considering an arbitrary x in S and 
showing 

and this is immediate because U is the least upper bound operation in D. To see 
that \JY is the least upper bound of Y let /i be an upper bound of Y and we 
shall show that \JY C' f 1 . This amounts to showing 

U{f x\f eY}nf lX 

for an arbitrary x (E S. However, this is immediate because fi x must be an upper 
bound of { / x | / G Y } and because U is the least upper bound operation in D. 

To prove the other part of the lemma assume that D is a ccpo and that Y is 
a chain in S — > D. The formula 

(U'Y)x = U{f x\f E Y } 

defines an element U' Y of S — > D: each { / x \ f G Y } will be a chain in D 
because Y is a chain and hence each |J{ / x \ f G F } exists because D is a ccpo. 
That |_|' y is the least upper bound of Y in S — > D follows as above. □ 

Instantiating S to be Var U {on-track} and D to be P we get: 



Corollary 5.5 Let Cps be the ordering on PState defined by 

P s i ^ps P s 2 if and only if psi x Cp ps 2 x for all x G Var U {on-track} 

Then (PState, Cps) is a complete lattice. In particular, the least upper bound 
LJps Y of a subset Y of PState is characterized by 

(Ups Y) x = Up { psx | ps G Y } 
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We shall write lost for the property state ps that maps all variables to D? and 
that maps 'on-track' to D?. Similarly, we shall write init for the property state 
that maps all variables to OK and that maps 'on-track' to OK. Note that init is 
the least element of PState. 

Exercise 5.6 (Essential) Show that 

P s i ^ps P s 2 if and only if OK(psi) 3 OK(ps 2 ) 
Next show that 

OK(Ups Y) = n{ OK(ps) I ps e Y } 
whenever Y is a non-empty subset of PState. □ 

Properties of rel 

To study the properties of the parameterized relation rel we need a notion of an 
equivalence relation. A relation 

R: E x E ->■ T 

is an equivalence relation on a set E if and only if 

R(ei, ei) (reflexivity) 
R(ei, e 2 ) and R(e 2 , e 3 ) imply R(ei, e 3 ) (transitivity) 
R(ei, e 2 ) implies R(e 2 , ei) (symmetry) 

for all ei, e 2 and e 3 of E. 

Exercise 5.7 Show that relA exp (p), reiR PYp (p) and rel stm (ps) are equivalence re- 
lations for all choices of p 6 P and ps 6 PState. □ 

Each of relAexp, leleexp and rel Stm are examples of parameterized (equivalence) 
relations. In general a parameterized relation is of the form 

71: D ->■ (E x £ ->■ T) 

where (D, C) is a partially ordered set, E is a set and each 7?.(o?) is a relation. We 
shall say that a parameterized relation 1Z is a Kripke-relation if 

c?i C o? 2 implies that for all ei, e 2 6 E: 

if 7J(di)(ei, e 2 ) then 1Z(d 2 )(e l , e 2 ) 

Note that this is a kind of monotonicity property. 
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Lemma 5.8 rel stm is a Kripke-relation. 

Proof: Let ps\ and ps 2 be such that psi Cps ps 2 and assume that 

Si = s 2 rel psi 
holds for all states si and s 2 . We must show 

si = 5 2 rel ps 2 

If ps 2 on-track = D? this is immediate from the definition of rel Stm . So assume 
that ps 2 on-track = ok. In this case we must show 

Vx £ OK(p5 2 ) n Var: si a; = <s 2 x 

Since psi Cps ^5 2 and ps 2 on-track = ok it must be the case that ps\ on-track is 
OK. From si = s 2 rel ps\ we therefore get 

Vx £ OK(psi) fl Var: si x = 5 2 x 

From Exercise 5.6 and the assumption psi Cps ps 2 we get OK(psi) D OK(^ 2 ) 
and thereby we get the desired result. □ 

Exercise 5.9 (Essential) Show that reU^p and rel B ex P are Kripke-relations. □ 

5.2 The analysis 

When specifying the analysis we shall be concerned with expressions as well as 
statements. 

Expressions 

The analysis of an arithmetic expression a will be specified by a (total) function 
TVtJa] from property states to properties: 

VA: Aexp ->■ (PState ->■ P) 

Similarly, the analysis of a boolean expression b will be defined by a (total) function 
/ P<8[6] from property states to properties: 

VB: Bexp ->■ (PState ->■ P) 
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VA\n\ps 


I (\W if Tie t \r\ trpr»V — f\W 
1 vj±v 11 po Ull-lldClv — vj±v 

1 D? otherwise 
i. 


VA\x\ps 


[ ps x if ps on-track = ok 

= { 

1 D? otherwise 


VAld! + a 2 \ps 


= (VA[ ai ]ps) Up (VA{a 2 jps) 


TA{a 1 * a 2 \ps 


= (VAMps) Up (VA{a 2 jps) 


VA\a 1 - a 2 \ps 


= (VA[ ai ]ps) Up (VA\a 2 \ps) 


VB{truejps 


1 VJ-tv 11 p& Ull-lldCK — KJi\. 

1 D? otherwise 
i. 


VB\f3lse\ps 


[ OK if ps on-track = ok 

= { 

1 D? otherwise 


VB\ai = a 2 \ps 


= (VA[ ai ]ps) Up (VA[a 2 ]ps) 


VB[ ai < a 2 \ps 


= (VA[ ai ]ps) Up (VA{a 2 jps) 


VB\-^ bjps 


= VB\b\ps 


VB[h A b 2 \ps 


= (VB[h\p8) Up {VB{b 2 \ps) 


Table 5.1: Analysis of expressions 



The defining clauses are given in Table 5.1. The clause for n reflects that the value 
of n in a proper property state ps does not depend on any variable and therefore 
it will have the property OK. The property of a variable £ in a proper property 
state ps is the property bound to x in ps, that is ps x. Thus if ps is the initial 
property state then the intention is that P^JxJps is OK if and only if x is one of 
the input variables. For a composite expression, like oi + a 2 , the idea is that it 
can only have the property OK if both subexpressions have that property. This is 
ensured by the binary operation U P introduced in Section 5.1. 

Example 5.10 If ps x = OK and ps on-track = OK then VA{x + ljps — OK 
since P^lfxjps = OK and "P.4|l]]ps = OK. On the other hand, if ps x = D? then 
VA{x + ljps = d? because VA{x]ps = d?. 

Furthermore, VB{x — xjps — D? if ps x = D? even though the test x = x will 
evaluate to tt independently of whether or not x is initialized properly. □ 

The functions P.AJa] and are closely connected with the sets of free 

variables defined in Chapter 1: 
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VS[x := aj ps = ps[x^VA[a\ps] 
P<S[skip] = id 

VS{S 1 ;S 2 \ = VS{S 2 \ o VS{S 1 \ 

VS[it b then Si else S 2 ] = cond P (PB[&], PS[Si], PS[S 2 ]) 
"PS [while b do S] = FIX H 

where # /i = cond P (VB{b}, h o VS[S\, id) 

Table 5.2: Analysis of statements in While 

Exercise 5.11 (Essential) Prove that for every arithmetic expression a we have 

VA{a\ps = OK if and only if FV(o) U {on-track} C OK{ps) 

Formulate and prove a similar result for boolean expressions. Deduce that for all 
a of Aexp we get TVlJaJps = D? if ps is improper, and that for all b of Bexp we 
get "PBJ&Jps = D? if ps is improper. □ 

Statements 

Turning to statements we shall specify their analysis by a function VS of func- 
tionality: 

VS: Stm ->■ (PState ->■ PState) 

The totality of P<S[S] reflects that we shall be able to analyse all statements 
including a statement like while true do skip that loops. The definition of VS is 
given in Table 5.2 and the clauses for assignment, skip and composition are much 
as in the direct style denotational semantics of Chapter 4. The remaining clauses 
will be explained below. 

Example 5.12 Consider the statement 
y := x 

First assume that ps is a proper property state with ps x — OK and ps y — D?. 
Then we have 

(VSy := xjps) x = OK 
(VSly := xjps) y = OK 
(VS{y := xjps) on-track = OK 
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Since VSfy :— xjps is proper we conclude that both x and y only depend on the 
input variables after y is assigned a value that only depends on the input variables. 
Assume next that ps y — OK but ps x — D?. Then 



showing that when a dubious value is used in an assignment then the assigned 



Exercise 5.13 Consider the statements S\ and S 2 of Example 5.3. Use Tables 
5.1 and 5.2 to characterize the behaviour of "PtSJi?!] and / P<S[iS , 2 ] on proper and 
improper property states. Anticipating Section 5.3 show that 

si = s 2 rel ps implies SdsISil^i = <S ds [5 , i]5 2 rel VS{Si}ps 



In the clause for if b then S\ else S 2 we use the auxiliary function condp 
defined by 



First consider the case where we are successful in analysing the condition, that is 
where f ps — OK. For each variable x we can determine the result of analysing 
each of the branches, namely (hi ps) x for the true branch and (h 2 ps) x for the 
false branch. The least upper bound of these two results will be the new property 
bound to x, that is the new property state will map x to 

((/ii ps) x) Up ((h 2 ps) x) 

If the analysis of the condition is not successful, that is / ps — D?, then the analysis 
of the conditional will fail and we shall therefore use the property state lost. 

Example 5.14 Consider now the statement 

if x = x then z :— y else y :— z 

Clearly, the final value of z can be determined uniquely from the initial value of 
y. However, if z is dubious then the analysis cannot give this result. To see this 
assume that ps is a proper property state such that ps x — ok, ps y — OK and 
ps z — D?. Then 

("PtSfif x = x then z := y else y := zjps) z 



(VS{y := xjps) y = D? 



variable will get a dubious value as well. 



□ 



for i = 1, 2 and for all ps £ PState. 



□ 




(cond P 0P£[x = x], VS{z : 
[VS\z := y] ps Up VS{y : 



y], VS{y := z]) ps) z 
z] ps) z 



= D? 
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because VB[x = xjps = OK, (VS[z := j]ps) z = OK but (VS{y := z]ps) z = D?. 
So even though the false branch never will be executed it will influence the result 
obtained by the analysis. 

Similarly, even if y and z are not dubious but x is, the analysis cannot determine 
that the final value of z only depends on the value of y. To see this assume that 
ps is a proper property state such that ps x = D?, ps y = OK and ps z = ok. We 
then get 

VS\i.f x = x then z := y else y := zjps 

= cond P 0P£[x = x], VS\z := y], VS\y := z\)ps 
= LOST 

because VB\x = xjps — D?. These examples show that the result of the analysis 
is safe but usually somewhat imprecise. More complex analyses could do better 
(for example by trying to predict the outcome of tests) but in general no decidable 
analysis can provide exact results. □ 

Exercise 5.15 Consider the statements Sn and 5 12 of Example 5.3. Use Tables 
5.1 and 5.2 to characterize the behaviour ofVSlSnJ and "PtSJi?^] on proper and 
improper property states. Anticipating Section 5.3 show that 

si = s 2 rel ps implies Sdsl-S^i = <S ds [5 , i]5 2 rel VS{Silps 

for i = 11, 12 and for all ps €E PState. Finally argue that it would not be sensible 
to use 

cond^(/, h u h 2 ) ps = (/ii ps) U PS (h 2 ps) 
instead of the condp defined above. □ 

In the clause for the while-loop we also use the function condp and otherwise 
the clause is as in the direct style denotational semantics of Chapter 4. In particular 
we use the fixed point operation FIX as it corresponds to unfolding the while-loop 
a number of times — once for each time the analysis traverses the loop. As in 
Chapter 4 the fixed point is defined by 

FIX # = |J{# n -L|n>0} 

where the functionality of H is 

H: (PState ->■ PState) ->■ (PState ->■ PState) 

and where PState — > PState is the set of total functions from PState to PState. 
In order for this to make sense H must be a continuous function on a ccpo with 
_L as its least element. We shall shortly verify that this is indeed the case. 
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Example 5.16 We are now in a position where we can attempt the application 
of the analysis to the factorial statement: 

VS{y := 1; while -(x=l) do (y := y*x; x := x-l)] 

We shall apply this function to the proper property state pso that maps x to OK 
and all other variables (including y) to D? as this corresponds to viewing x as the 
only input variable of the statement. 

To do so we use the clauses of Tables 5.1 and 5.2 and get 

VSfy :— 1; while -i(x=l) do (y := y*x; x := x— 1)] ps 

= (FIX H) (ps [y^OK]) 

where 

H h = cond P (7 7 ^h(x=l)], h o VS\y := y*x; x := x-l], id) 

We first simplify H and obtain 

LOST if ps on-track = D? or ps x = D? 

(h ps) Up S ps if ps on-track = OK and psx — OK 

At this point we shall pretend that we have shown the following property of H (to 
be proved in Exercise 5.18): 

if H n _L = H n+1 ± for some n 
then FIX H = H n _L 

where _L is the function _L ps — init for all ps. We can now calculate the iterands 
H° ±, H 1 _L, • • -. We obtain 



(H h) ps = 



(H° _L) ps = INIT 

LOST if ps x = D? or ps not proper 

ps if ps x = OK and ps proper 

LOST if ps x = D? or ps not proper 

ps if ps x = OK and ps proper 



(H 1 _L) ps = 



(H 2 _L) ps = 



where ps is an arbitrary property state. Since H 1 _L = H 2 _L our assumption above 
ensures that we have found the least fixed point for H: 

( LOST if ps x = D? or ps not proper 
(FIX H) ps = \ 

{ ps if ps x = OK and ps proper 

It is now straightforward to verify that (FIX H) (pso[yi- >Ok]) y = OK and that 
(FIX H)(pso[y\-K)K]) is proper. We conclude that there is a functional dependency 
between the input variable x and the output variable y. □ 
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Well-definedness of VS 

Having specified the analysis we shall now show that it is indeed well-defined. As 
in Chapter 4 there are three stages: 

• First we introduce a partial order on PState — > PState such that it becomes 
a ccpo. 

• Then we show that certain auxiliary functions used in the definition of VS 
are continuous. 

• Finally we show that the fixed point operator only is applied to continuous 
functions. 

Thus our first task is to define a partial order on PState — f PState and for this 
we use the approach developed in Lemma 5.4. Instantiating the non-empty set S 
to the set PState and the partially ordered set (D, C) to (PState, Cps) we get: 

Corollary 5.17 Let C be the ordering on PState — > PState defined by 

hi C h 2 if and only if hi ps C PS h 2 ps for all property states ps 

Then (PState — > PState, C) is a complete lattice, and hence a ccpo, and the 
formula for least upper bounds is 

(U Y) ps = Ups { h ps | h e Y } 

for any subset Y of PState — > PState. 

Exercise 5.18 (Essential) Show that the assumption made in Example 5.16 is 
correct. That is first show that 

H: (PState ->■ PState) ->■ (PState ->■ PState) 

as defined in Example 5.16 is indeed a monotone function. Next show that for any 
monotone function H of the above functionality if 

H n _L = H n+1 ± 

for some n then H n _L is the least fixed point of if. □ 

Our second task is to ensure that the function H used in Table 5.2 is a con- 
tinuous function from PState — > PState to PState — > PState. For this we 
follow the approach of Section 4.3 and show that condp is continuous in its second 
argument and later that composition is continuous in its first argument. 
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Lemma 5.19 Let /: P State — > P, h : P State — > P State and define 

H h — condp(/, h, ho) 
Then H: (PState— )-PState) — > (PState— KPState) is a continuous function. 



Proof: We shall first prove that H is monotone so let hi and h 2 be such that 
hi E h 2 , that is hi ps C PS h 2 ps for all property states ps. We then have to show 
that condp(/, hi, ho) ps C PS condp(/, h 2 , ho) ps. The proof is by cases on the 
value of / ps. If / ps — OK then the result follows since 

(hi ps) U PS (h ps) C PS (h 2 ps) U PS (h ps) 

If / ps — D? then the result follows since lost C ps lost. 

To see that H is continuous let Y be a non-empty chain in PState — > PState. 
Using the characterization of least upper bounds in PState given in Corollary 5.17 
we see that we must show that 



for all property states ps in PState. The proof is by cases on the value of / ps. 
If / ps — D? then we have (H (U^)) P$ — lost and 



where the last equality is because Y is not empty. Thus we have proved the 
required result in this case. If / ps — OK then the characterization of least upper 
bounds in PState gives: 



(H (UY)) ps — Ups { (H h) ps \ h E Y } 



Ups { (H h) ps | h e Y } = Up S { lost | h £ Y } 



= LOST 



(H (UY)) ps 



((UY) ps) U PS (h ps) 

(Ups { h ps | h E Y }) U PS (h ps) 

Ups { h ps | h e Y U {h }} 



and 



Ups { (H h) ps 



he Y } — Ups { (h ps) U PS (h ps) \ h £ Y } 
= Ups { h ps | h e Y U { h Q } } 



where the last equality follows because Y is not empty. Thus the result follows in 
this case. □ 
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Exercise 5.20 Let /: PState — > P, h : PState — > PState and define 

Eh — condp(/, ho, h) 

Show that H: (PState — > PState) — > (PState — > PState) is a continuous func- 
tion. □ 



Lemma 5.21 Let ho'- PState — > PState and define 
H h = h o ho 

Then H: (PState— ^PState) — > (PState— >-PState) is a continuous function. 

Proof: We shall first show that H is monotone so let hi and h 2 be such that 
hi C h 2 , that is hi ps C PS h 2 ps for all property states ps. Clearly we then have 
hi(ho ps) Cps h 2 (ho ps) for all property states ps and thereby we have proved the 
monotonicity of H. 

To prove the continuity let Y be a non-empty chain in PState — > PState. 
We must show that 

(H (UY)) ps = (|J{ H h | h E Y }) ps 

for all property states ps. Using the characterization of least upper bounds given 
in Corollary 5.17 we get 

(H {UY)) ps = ((UY) o h ) ps 
= (UY) (h ps) 
= Ups { h (h ps)\h£Y} 

and 

(|J{ H h | h e Y }) ps = Ups { (H h) ps \ h e Y } 

= Ups {(ho h ) ps \ h e Y } 
Hence the result follows. □ 
This suffices for showing the well-definedness of VS: 



Proposition 5.22 The semantic function 7^5 [5]: PState — > PState of Table 
5.2 is a well-defined function for all statements S of the language While. 



Proof: The proof is by structural induction on S and only the case of the while- 
loop is interesting. We note that the function H used in Table 5.2 is given by 
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H = H 1 o H 2 

where 

H 1 h = cond P (PS[6], h, id) 
H 2 h = ho VS{Sj 

As ffi and H 2 are continuous functions by Lemmas 5.19 and 5.21 we have that 
if is a continuous function by Lemma 4.35. Hence FIX H is well-defined and this 
completes the proof. □ 



Exercise 5.23 Consider the statement 

z := 0; while y<x do (z := z+1; x := x— y) 

where x and y are input variables and z is the output variable. Use the approach 
of Example 5.16 to show that there is a functional dependency between the input 
and output variables. □ 

Exercise 5.24 Apply the analysis VS to the statement while true do skip and 
explain why the analysis terminates. □ 

Exercise 5.25 Extend While with the statement repeat S until b and give 
the new (compositional) clause for VS. Discuss your extension and validate the 
well-definedness. □ 



Exercise 5.26 Extend While with the statement for x :— a\ to a 2 do S and 
give the new (compositional) clause for VS. Discuss your extension and validate 
the well-definedness. □ 

Exercise 5.27 (Essential) Show that for every statement S 

ps on-track IZ (VS{S}ps) on-track 

so that ps must be proper if "P<S[iS']p<5 is. In the case of while b do S you should 
first prove that for all n > 1: 

ps on-track C ((# n -L) ps) on-track 

where ± ps' = init for all ps' and H h = cond P (P£[&], h o VS[S], id). □ 



Exercise 5.28 Show that there exists h : PState — > PState such that H defined 
by H h = h o h is not even a monotone function from PState — > PState to 
PState ->• PState. □ 



152 



5 Static Program Analysis 



Remark The example of the above exercise indicates a major departure from the 
secure world of Chapter 4. Luckily an insurance policy can be arranged. The 
premium is to replace all occurrences of 

PState ->■ PState and PState ->■ P 

by 

[PState ->■ PState] and [PState ->■ P] 

where [D — > E] — { /: D — > E \ f is continuous }. One can then show that 
[D — > E] is a ccpo if D and E 1 are and that the characterization of least upper 
bounds given in Lemma 5.4 still holds. Furthermore, one can show that Exercise 
5.6 ensures that "P^4[a] and are continuous. Finally, the entire development 

in this section still carries through although there are additional proof obligations 
to be carried out. In this setting one gets that if h : [PState — > PState] then H 
defined by H h = h o h is indeed a continuous function from [PState — > PState] 
to [PState ->■ PState]. □ 
To summarize, the well-definedness of VS relies on the following results estab- 
lished above: 





Proof Summary for While: 




Well-definedness of Static Analysis 


1: 


The set PState — > PState equipped with an appropriate ordering C is 




a ccpo (Corollary 5.17). 


2: 


Certain functions *: (PState -> PState) -> (PState -> PState) are 




continuous (Lemmas 5.19 and 5.21). 


3: 


In the definition of VS we only apply the fixed point operation to contin- 




uous functions (Proposition 5.22). 



Our overall algorithm for determining whether or not there is a functional depen- 
dency between input and output variables then proceeds as follows: 

INPUT: a statement S of While 

a set / C Var of input variables 

a set C Var of output variables 
OUTPUT: YES, if there definitely is a functional dependency 

NO?, if there may not be a functional dependency 
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METHOD: let psj be uniquely determined by OK(psj) = / U {on-track} 
let ps = VSlSjps! 

output YES if OK(pso) 3 U {on-track} 
output NO? otherwise 

5.3 Safety of the analysis 

In this section we shall show that the analysis functions VA, VB and VS are 
correct with respect to the semantic functions A, B and S<\ s . This amounts to a 
formalization of the considerations that were already illustrated in Exercises 5.13 
and 5.15. We begin with the rather simple case of arithmetic expressions. 

Expressions 

Let g: State — > Z be a function, perhaps of the form A\a\ for some arithmetic 
expression a £ Aexp, and let h: PState -> P be another function, perhaps of 
the form "P^4[a] for some arithmetic expression a £ Aexp. We shall introduce a 
relation 

g sat a p Y p h 

for expressing when the analysis h is correct with respect to the semantics g. It is 
defined by 

si = s 2 re!s tm ps implies g si = g s 2 relAexp h ps 

for all states s\ and s 2 and property states ps. This condition says that the results 
of g will be suitably related provided that the arguments are. It is perhaps more 
intuitive when rephrased as 

(si = s 2 relgtm ps) and (h ps — ok) imply g si = g s 2 

The safety of the analysis VA is then expressed by 

Fact 5.29 For all arithmetic expressions a £ Aexp we have 
Ala} satA exp VA[a\ 

Proof: This is an immediate consequence of Lemma 1.11 and Exercise 5.11. □ 

The analysis VB of boolean expressions is safe in the following sense: 

Exercise 5.30 (Essential) Repeat the development for boolean expressions, that 
is define a relation satR PYp and show that 

B\b\ satB exp VB{b] 

for all boolean expressions b £ Bexp. □ 
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Statements 

The safety of the analysis of statements will express that if OK (ps) includes all 
the input variables and if OK(V S{S}ps) includes 'on-track' and all the output 
variables then Sdsl^] determines a functional relationship between the input and 
output variables. This validation is important because although the intuition 
about OK meaning "depending only on input variables" goes a long way towards 
motivating the analysis, it is not perfect. As we already mentioned in Section 5.1 
one cannot inspect a value, like 27, and determine whether it has its value because 
it only depends on input variables or because it just happened to be 27. To aid 
the intuition in determining that no errors have been made in the definition of 
the analysis it is necessary to give a formal statement of the relationship between 
computations in the standard (denotational) semantics and in the analysis. 

Our key tool will be the relation si = s 2 rel ps and we shall show that if this 
relationship holds before the statement is executed and analysed then either the 
statement will loop on both states or the same relationship will hold between the 
final states and the final property state (provided that the analysis does not get 
"lost"). We shall formalize this by defining a relation 

9 satstm h 

between a function g: State <^-> State, perhaps of the form <Sds[<Sl f° r some S in 
Stm, and another function h: PState — > PState, perhaps of the form 7-\S[5] for 
some S in Stm. The formal definition amounts to 

(si = s 2 rel ps) and (h ps is proper) 

imply 

(g Si = undef and g s 2 — undef ) or 

(g Si ^ undef and g s 2 ^ undef and g si = g s 2 rel h ps) 

for all states si, s 2 £ State and all property states ps 6 PState. To motivate 
this definition consider two states si and s 2 that are equal relative to ps. If ps is 
proper this means that si x — s 2 x for all variables x in OK(ps). The analysis 
of the statement may get "lost" in which case h ps is not proper and we cannot 
deduce anything about the behaviour of the statement. Alternatively, it may be 
the case that h ps is proper and in that case the statement must behave in the 
same way whether executed from s\ or from s 2 . In particular 

• the statement may enter a loop when executed from s\ and s 2 , that is 
g si = undef and g s 2 = undef , or 

• the statement does not enter a loop when executed from si and s 2 , that is 
g S\ ^ undef and g s 2 ^ undef . 
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In the latter case the two final states g Si and g s 2 must be equal relative to the 
resulting property state h ps, that is (g Si) x — (g s 2 ) x for all variables x in 
OK(h ps). 

We may then formulate the desired relationship between the semantics and the 
analysis as follows: 

Theorem 5.31 For all statements S of While we have <Sds[<Sl saW ™ 7^5 [5]. 



Before conducting the proof we need to establish some properties of the auxil- 
iary operations composition and conditional. 



Lemma 5.32 Let gi, g 2 : State <^-» State and hi, h 2 . PState — > PState and 

assume that 

ps on-track C P (h 2 ps) on-track (*) 
holds for all ps E PState. Then 

91 satstm hi and g 2 sat S tm h 2 imply g 2 o gi sat Stm h 2 o h t 

Proof: Let Si, s 2 and ps be such that 

Si = s 2 rel ps, and (h 2 o hi) ps is proper 

Using that h 2 (hi ps) is proper we get from (*) that hi ps must be proper as well 
(by taking ps to be hi ps). So from the assumption gi sats tm hi we get 

gi Si = undef and gi s 2 — undef, or 

gi Si ^ undef and gi s 2 ^ undef and gi Si = gi s 2 rel hi ps 

In the first case we are finished since it follows that (g 2 o gi) si — undef and that 
{92 9i) s 2 — undef . In the second case we use that 

gi si = gi s 2 rel hi ps, and h 2 (hi ps) is proper 

The assumption g 2 satstm h 2 then gives 

92 (91 Si) — undef and g 2 (gi s 2 ) = undef , or 
92 (91 Si) 7^ undef and g 2 (gi s 2 ) ^ undef and 

52(^1 si) = g 2 (gi s 2 ) rel h 2 (hi ps) 

In both cases we have completed the proof. □ 
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Lemma 5.33 Assume that gi, g 2 : State <^-> State, and g: State — > T and that 
hi, h 2 : PState ->■ PState and /: PState ->■ P. Then 

5 sateexp /, gi satstm /*i and g 2 satstm /*2 imply 
cond(#, g u g 2 ) satstm cond P (/, /ii, h 2 ) 

Proof: Let si, s 2 and ps be such that 

Si = s 2 rel and condp(/, /ii, /i 2 ) £><s is proper 

First assume that f ps — D?. This case turns out to be impossible since then 
condp(/, hi, h 2 ) ps — lost so condp(/, hi, h 2 ) ps cannot be proper. 

So we know that f ps — OK. From g sateexp / we then get g Si — g s 2 . We 
also get that condp(/, hi, h 2 ) ps — (hi ps) U PS (h 2 ps). Thus hi ps as well as h 2 
ps must be proper since otherwise condp(/, hi, h 2 ) ps cannot be proper. Now let 
i denote the branch chosen by the test g. We then have 

Si = s 2 rel ps and hi ps is proper 

From the assumption gi sats tm hi we therefore get 

gi Si — undef and gi s 2 — undef, or 

gi si ^ undef and gi s 2 ^ undef and 54 si = gi s 2 rel hi ps 
In the first case we get 

cond(g, gi, g 2 ) Si — undef and cond(<7, gi, g 2 ) s 2 — undef 
and we are finished. In the second case we get 

cond(<7, gi, g 2 ) Si ^ undef and cond(^, gi, g 2 ) s 2 ^ undef 
Furthermore, we have 

cond(#, gi, g 2 ) Si = cond(^, gi, g 2 ) s 2 rel h { ps 

Clearly hi ps C hi ps U PS h 2 ps and using the definition of condp and Lemma 5.8 
we get 

cond(#, gi, g 2 ) Si = cond(#, gi, g 2 ) s 2 rel cond P (/, hi, h 2 ) ps 
as required. □ 

We now have the apparatus needed to show the safety of VS: 

Proof of Theorem 5.31: We shall show that <Sds[<Sl satstm ^^[iS 1 ] and we 
proceed by structural induction on the statement S. 

The case x :— a: Let Si, s 2 and ps be given such that 
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Si = s 2 rel ps and VS\x :— ajps is proper 

It then follows from Exercise 5.27 that ps is proper because VS\x :— ajps is. Also 
both S ds {x :— ajsi and S ds {x '■ — o,}s 2 will be defined so we only have to show that 

(S ds {x := a]si) y = (S da {x := o]a 2 ) y 

for all y £ Var n OK{VS{x := o]pa). If y ^ z and y is in OK{VS{x := o]pa) then 
y 6 OK(ps) and it is immediate from the definition of S^s that (tSdsI^ := a]si) y 
— (^dsl^ : — o]<S2) y- li y — x and x is in OK("P<S[a; := ajps) then we use the 
assumption si = s 2 rel together with (PS [a; := ajps) x — OK to get 

Ala} Sl = A[a\s 2 

by Fact 5.29. Hence (Sdsl^ := y = (Sdsl^ := a]^) y follows also in this 

case. This proves the required relationship. 

The case skip: Straightforward. 

The case S\]S 2 '. The induction hypothesis applied to S\ and gives 

S ds {Si\ satstm VS\Si\ and S ds {S 2 j sat Stm VS{S 2 j 

It follows from Exercise 5.27 that ps on-track C P (VSlS 2 }ps) on-track holds for 
all property states ps. The desired result 

<S ds [S 2 ] o S ds lS 1 j satstm VSIS 2 ] o VSiSd 
then follows from Lemma 5.32. 

The case if b then Si else S 2 : From Exercise 5.30 we have 

B[b] satB exp VB[b] 
and the induction hypothesis applied to Si and S 2 gives 

S ds {Sil sats tm VSlSij and <S ds [S 2 ] satstm P<S[S 2 ] 
The desired result 

cond(B[6], S ds {Sil S ds {S 2 }) sat stm cond P 7>S[S 2 ]|) 

then follows from Lemma 5.33. 

The case while b do S: We must prove that 

FIX(G) satstm FIX (if) 

where 
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G g = cond (B[b], g o <S ds [<?], id) 
H h = condp (VB{bJ, h o VS[S\, id) 

To do this we recall the definition of the least fixed points: 

FIX G = \J{G n g | n > } where g s = undef for all s 
FIX H = U{H n h | n > } where h ps = init for all ps 

The proof proceeds in two stages. We begin by proving that 

G n g satstm FIX H for all n (*) 
and then 

FIX G sat stm FIX H (**) 
We prove (*) by induction on n. For the base case we observe that 
#o satstm FIX H 

holds trivially since g s — undef for all states s. For the induction step we assume 
that 

G n g satstm FIX H 
and we shall prove the result for n+1. We have 

B[b] satBexp VB[b] 
from Exercise 5.30, 

IS} satstm VS{S] 

from the induction hypothesis applied to the body of the while-loop, and it is 
clear that 

id satstm id 
By Exercise 5.27 we also have 

ps on-track C P ((FIX H) ps) on-track 

for all property states ps. We then obtain 

cond(B[6], (G n </ )°<S ds [S], id) satstm cond P (PB[6], (FIX H)oVS{Sl id) 

from Lemmas 5.32 and 5.33 and this is indeed the desired result since the right- 
hand side amounts to H (FIX H) which equals FIX H. 
Finally we must show (**). This amounts to showing 

U Y sats tm FIX H 
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where Y — { G n go | n > }. So assume that 

Si = s 2 rel ps and (FIX H) ps is proper 
Since g sats tm FIX H holds for all g £ Y by (*) we get that either 

g si = undef and g s 2 = undef , or 

g si ^ undef and g s 2 ^ undef and g si = g s 2 rel (FIX H) ps 

If ([J F) 5i = undef then g S\ = undef for all g £ F and thereby g s 2 — undef for 
all g £ Y so that (|J Y) s 2 — undef . Similarly (|J Y) s 2 — undef will imply that 
(\_\Y) si — undef . So consider now the case where (LJF) s i undef as well as 
(LJF) s 2 ^ undef and let x £ Var n OK((FIX H) ps). By Lemma 4.25 we have 

graph(|J Y) = U{ graph g \ g £ Y } 

and (U Y) s ; ^ undef therefore shows the existence of an element g x in Y such 
that <?i Si 7^ undef and (\_\Y) s ; = <?i s ; (for i = 1, 2). Since F is a chain either 
<7i E <?2 or # 2 Q gi so let (/ be the larger of the two. We then have 

((U^) «i) x = {gi si) x as QJF) ai = #i Si 

= (# 5i) x as #i C ^ and <?i Si ^ undef 

= (g s 2 ) x as g si = g s 2 rel (FIX if) 

= (#2 -S2) ^ as #2 Q g and 5» 2 <?2 7^ undef 

= ((UF) S2 )x as (LJF) s 2 = g 2 s 2 

as required. This finishes the proof of the theorem. □ 

It follows from this theorem that the algorithm listed at the end of Section 5.2 
is indeed correct. The proof of safety of the analysis can be summarized as follows: 



Proof Summary for While: 
Safety of Static Analysis 



1: Define a relation sats tm expressing the relationship between the functions 
of State State and PState ->■ PState. 

2: Show that the relation is preserved by certain pairs of auxiliary functions 
used in the denotational semantics and the static analysis (Lemmas 5.32 
and 5.33). 

3: Use structural induction on the statements S to show that the relation 
holds between the semantics and the analysis of S. 



160 



5 Static Program Analysis 



Exercise 5.34 Extend the proof of the theorem to incorporate the analysis de- 
veloped for repeat S until b in Exercise 5.25. □ 

Exercise 5.35 When specifying VS in the previous section we rejected the pos- 
sibility of using 

cond P (/, h u h 2 ) ps = (hi ps) U PS (h 2 ps) 

rather than condp. Formally show that the analysis obtained by using condp rather 
than condp cannot be correct in the sense of Theorem 5.31. Hint: Consider the 
statement S i 2 of Example 5.3. □ 

Exercise 5.36 In the above exercise we saw that condp could not be simplified 
so as to ignore the test for whether the condition is dubious or not. Now consider 
the following remedy 

condp (/, h u h 2 ) ps 

(hi ps) U PS (h 2 ps) if f ps = OK 

= < ((hi (ps[on-tracki-»D?])) U PS (h 2 (ps[on-tracki->-D?])))[on-tracki->-OK] 

if / ps = D? 

Give an example statement where condp is preferable to condp. Does the safety 
proof carry through when condp is replaced by condp? If not, suggest how to 
weaken the safety predicate such that another safety result may be proved. □ 



5.4 Bounded iteration 

In Example 5.16 we analysed the factorial statement and saw that the fixed point 
computation stabilizes after a finite number of unfoldings, irrespective of the prop- 
erty state that is supplied as argument. This is quite unlike what was the case for 
the denotational semantics of Chapter 4, where the number of unfoldings depended 
on the state and was unbounded. A similar example was studied in Exercise 5.24 
where we saw that the analysis would terminate upon a statement that never 
terminated in the denotational semantics of Chapter 4. 

This is an instance of a general phenomenon and we shall show two propositions 
about this. The first proposition says that for each statement while b do S there 
is a constant k such that the kth unfolding will indeed be the fixed point. The 
second proposition is considerably harder and says that it is possible to take k to 
be (m+1) 2 where m is the number of distinct variables in while b do S. 

To prepare for the first proposition we need an inductive definition of the set 
FV(iS') of free variables in the statement S: 
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FV(x := a) = FV(o) U {x} 

FV(skip) = 

FV(5i;5 2 ) = FV(Si) U FV(S 2 ) 

FV(if b then Si else S 2 ) = FV(6) U FV(Si) U FV(S 2 ) 

FV(while 6 do 5) = FV(6) U FV(5) 

Our first observation is that we can repeat the development of the previous sections 
if we restrict the property states to consider only variables that are free in the 
overall program. So let X C Var be a finite set of variables and define PState^ 
to be 

PState x = (X U {on-track}) ->■ P 

Exercise 5.37 (Essential) Define Aexpx to be the set of arithmetic expressions 
a of Aexp with FV(a) C X and let Bexpx and Stm^ be defined similarly. Modify 
Tables 5.1 and 5.2 to define analysis functions 

VA X - Aexp x ->■ PState x ->■ P 

VB X : Bexp x ->■ PState x ->• P 

P<S X : Stm x ->■ PState x ->■ PState x □ 

The connection between the analysis functions of the above exercise and those 
of Tables 5.1 and 5.2 should be intuitively clear. Formally the connection may be 
worked out as follows: 

Exercise 5.38 * Define 

extend^: PState^ — > PState 

by 



| ps x if x £ X U {on-track} 



(extend^ ps) x 

[ ps on-track otherwise 

Show that 

VA{a\ o extend* = VA x [a] 

VB{b\ o extend* = VB x [b] 

VS{Sj o extend* = extend* o VSx{S} 

whenever FV(o) C X, FV(6) C X and FV(5) C X. □ 

The property states of PState* are only defined on a finite number of argu- 
ments because X is a finite set. This is the key to showing: 
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Proposition 5.39 For each statement while b do S of While there exists a 
constant k such that 

VS X [while b do Sj = H k JL 

where H h = condp{VB x [b}, h o VS X [S\, id) and FV(while b do S) C X. 

Note that using the result of Exercise 5.38 we could dispense with X altogether. 

Proof: Let m be the cardinality of X. Then there will be 2 m+1 different property 
states in PState^. This means that PState-x — > PState^ will contain 

k = (2 m + 1 ) 2m+1 

different functions. It follows that there can be at most k different iterands H n _L 
of H. Since H is monotone Exercise 5.18 gives that H k _L must be equal to the 
fixed point FIX H. This concludes the proof of the proposition. □ 

Making it practical 

The constant k determined above is a safe upper bound but is rather large even 
for small statements. As an example it says that the 16,777,216th iteration of 
the functional will suffice for the factorial statement and this is quite useless for 
practical purposes. In the remainder of this section we shall show that a much 
smaller constant can be used: 



Proposition 5.40 For each statement while b do S of While we have 

VS X [while b do SJ = H k JL 

where Eh — condp^-SxM, h o VSx\S\, id), k = (m+1) 2 , and m is the cardi- 
nality of the set X = FV(while b do S). 

Note that using the result of Exercise 5.38 we could dispense with X altogether. 

For the factorial statement this will imply that FIX H — H 9 _L so only nine 
iterands need to be constructed. This may be compared with the observation made 
in Example 5.16 that already H 1 _L is the least fixed point. 

The proof of Proposition 5.40 requires some preliminary results. To motivate 
these consider why the upper bound determined in Proposition 5.39 is so imprecise. 
The reason is that we consider all functions in PState^ — > PState^ and do not 
exploit any special properties of the functions H n _L, such as monotonicity or 
continuity. To obtain a better bound we shall exploit properties of the "P<Sx[<51 
analysis functions. Recall that a function 
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h: PState x ->■ PState x 

is strict if and only if 

h INIT X — INITx 

where init^ is the least element of PState^- It is an additive function if and only 
if 

h (pai U PS ps 2 ) = (h pai) U PS (/i ps 2 ) 
holds for all property states psi and ps 2 of PState^. 

Exercise 5.41 (Essential) Give a formal definition of what it means for a func- 
tion 

h: PState x ->■ P 

to be strict and additive. Use Exercise 5.11 to show that TVLxM an d "P^xM 
are strict and additive. (We tacitly assume that FV(o) C X and FV(6) C X.) □ 

We shall first show that the auxiliary functions for composition and conditional 
preserve strictness and additivity and next we shall prove that the analysis function 
"P*Sx[<Sl is strict and additive for all statements S. 

Exercise 5.42 (Essential) Show that if h\ and h 2 are strict and additive func- 
tions in PStatex — > PState^ then so is hi o h 2 . □ 

Exercise 5.43 (Essential) Assume that / in PState^ — > P is strict and additive 
and that hi and h 2 in PState^ — > PState^ are strict and additive. Show that 
condp(/, hi, h 2 ) is a strict and additive function. Hint: if / (psi U PS ps 2 ) — D? 
then / psi — D? for i = 1 or i = 2. □ 



Lemma 5.44 For all statements S of While, 'PtSxH'S'] is a strict and additive 
function whenever FV(5) C X . 



Proof: We proceed by structural induction on S and assume that FV(5) C X. 
The case x :— a: We have 

VS x {x := a] miT x = mn x 

because Exercise 5.41 gives that "P^lxM is strict so "PA^M iniTy = OK. Next 
we show that VSx\x := a] is additive: 
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VS x {x := o](psi U PS ps 2 ) 

= (pai U PS pa 2 )[a;i-» 7Mx[a](pai U PS pa 2 )] 
= (pai U PS ps 2 )[x^ VAxlajps 1 U P 7Mx[a]pa 2 ] 
= psi[x^VAx{a\psi] U PS ps 2 [a!'-^7 ? -4x[o]ps2] 
= PSx[z := ajpsi U PS "P<Sx[z := a\ps 2 

where the second equality follows from "P.4x[[a] being additive (Exercise 5.41). 
The case skip is immediate. 

The case Si, S 2 follows from Exercise 5.42 and the induction hypothesis applied 
to Si and S 2 . 

The case if b then 5*1 else S 2 follows from Exercise 5.43, the induction hypoth- 
esis applied to Si and S 2 and Exercise 5.41. 

The case while b do S: Define 

H h = condp(PB x [6], h o VSxlSj, id) 
Our first claim is that 

H n ± 

is strict and additive for all n. This is proved by numerical induction and the 
base case, n = 0, is immediate. The induction step follows from the induction 
hypothesis of the structural induction, the induction hypothesis of the numerical 
induction, Exercises 5.42, 5.41 and 5.43 and that id is strict and additive. Our 
second claim is that 

FIX H = Up S { H n JL | n > } 

is strict and additive. For strictness we calculate 

(FIX H) initx = Ups { (# n _L) initx | n > } 
= miT x 

where the last equality follows from H n _L being strict for all n. For additivity we 
calculate 

(FIX H)(psi U PS ps 2 ) 

= Ups { (# n J-)(psi U PS ps 2 ) n > } 

= Ups { (# n ±)psi U PS (# n ±)ps 2 n > } 

= Ups { (# n ±)psi | n > } U PS Ups { (# n ±)ps 2 | n > } 

= (FIX H)psi U PS (FIX H)ps 2 
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The second equality uses the additivity of H n _L for all n. This concludes the proof 
of the lemma. □ 

Strict and additive functions have a number of interesting properties: 

Exercise 5.45 (Essential) Show that if h: PStatex — > PState^ is additive 
then h is monotone. □ 

The next result expresses that when two distinct analysis functions hi and h 2 
are strict and additive and satisfies hi C h 2 then it will be the property assigned 
to just one of the "variables" that accounts for the difference between hi and h 2 . 



Lemma 5.46 Consider strict and additive functions 

h u h 2 : P States ->■ PState x 

such that hi C h 2 and hi ^ h 2 . Then there exist "variables" x, y E X U {on-track} 
such that 

(hi (iNiTj^yi-^-D?])) x — ok but 

(h 2 (lNIT x [l/l->D?])) X — D? 



Proof: Since hi C /12 and /ii 7^ /i 2 there exists a property state ps such that 

PS C PS h 2 ps 
hi ps ^ h 2 ps 

It follows that there exists a "variable" x E X U {on-track} such that 

(/ii ps) x = OK 
(h 2 ps) x — D? 

Consider now the set OK(ps). It is finite because OK(ps) Clu {on-track}. First 
assume that OK(ps) = IU {on-track}. Then ps — miT x and since we know that 
hi and h 2 are strict we have hi miT x — wit x and h 2 mn x — wit x . Therefore 
hi ps — h 2 ps which contradicts the way ps was chosen. 

Therefore OK(ps) is a true subset of X U {on-track}. Now let {yi, ■ ■ -, y n } be 
the "variables" of X U {on-track} that do not occur in OK(ps). This means that 

PS = INIT X [yil->D?]- • -[l/nl-^D?] 

which is equivalent to 

£S = INIT x [l/il->D?] U PS ■ ■ ■ U PS INIT x [y n ^D?] 
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Since h 2 is additive we have 

h 2 ps = h 2 (wiT x [y 1 h^-D r ?]) U PS ••• U PS /i 2 (iNiT x [y n ^D?]) 
We have assumed that (h 2 ps) x — D? and now it follows that for some i (l<i<n) 

h 2 (miT x [yi\-^T)l]) x — D? 
Since iNiTx[yii— >-d?] C PS ps and hi is monotone (Exercise 5.45) we get that 

hi (miT x [y ;l— >D?]) Cpg hi ps 
and thereby 

hi (lNITx[yil->-D?]) x — OK 

So the lemma follows by taking y to be y\. □ 

The next step will be to generalize this result to sequences of strict and additive 
functions. 

Corollary 5.47 Consider a sequence 

h C hi C ■ ■ ■ C /i n 

of strict and additive functions 

PState x ->■ PState x 

that are all distinct, that is hi ^ if i ^ j. Then n < (m+1) 2 where m is the 
cardinality of X. 

Proof: For each i 6 {0,1,- • -,n— 1} the previous lemma applied to h\ and h- l+ i gives 
that there are "variables" 

X{, t/iflU {on-track} 

such that 

/li(lNIT x [yi^D?]) Xi = OK 
/l i+ l(lNIT x [yi^D?]) X; = D? 

First assume that all (x i: y{) are distinct. Since the cardinality of X is m there 
can be at most (m+1) 2 such pairs and we have shown n < (m+1) 2 . 

Next assume that there exists i < j such that (x{, yi) — (xj, yj). We then have 

/l i+ l(lNIT x [yi^D?]) Xi = D? 
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and 

/lj(lNIT x [yi^D?]) Xi = OK 

Since i+1 < j we have h- l+ i C h } - and therefore 

h i+1 (lNIT X [«/i^D?]) C P /lj (lNIT x [«/i^D?]) X; 

This is a contradiction as it is not the case that D? C P ok. Thus it cannot be the 
case that some of the pairs (x{, yi) obtained from Lemma 5.46 coincide and we 
have proved the corollary. □ 

We shall now turn towards the proof of the main result: 

Proof of Proposition 5.40. Consider the construct while b do S and let H be 

given by 

Hh = cond P (P£jr[6], h o VS X [S], id) 

We shall then prove that 

VS X [while b do Sj = H k JL 

where k = (m+1) 2 and m is the cardinality of X — FV (while b do S). To do that 
consider the sequence 

H° JL C if 1 JL C • • • C if k JL C if k+1 J_ 

It follows from Lemma 5.44 that each if 1 J_ is a strict and additive function. It 
now follows from Corollary 5.47 that not all H 1 J_, for i < k+1, are distinct. If i<j 
satisfies 

W JL = /fj JL 
then we also have 

W ± = H n ± for n>i 
and in particular 

H k ± = H k+1 ± 

Hence FIX H = H k J_ as desired because of Exercise 5.18. □ 

Exercise 5.48 * Show that the bound exhibited in Corollary 5.47 is tight. That 
is describe how to construct a sequence 

h C hi C ■ ■ ■ C h n 



168 



5 Static Program Analysis 



of strict and additive functions h^. PState^ — > PState^ such that all hi are dis- 
tinct and n = (m+1) 2 where m is the cardinality of X. Hint: Begin by considering 
m = 0, m = 1, m = 2 and then try to generalize. □ 

To summarize, the quadratic upper bound on the required number of iterands 
is obtained as follows: 



Proof Summary for While: 
Bounding the Number of Iterations in the Static Analysis 



1: The analysis is modified to use the set PState^ rather than PState 
(Exercise 5.37). 

2: A proof by structural induction on the statements shows that the analysis 
functions 7 7 <Sx[5'] are strict and additive (Lemma 5.44). 

3: Sequences of strict and additive functions in PState^ — > PState^ can 
have length at most (m+1) 2 where m is the cardinality of X (Corollary 
5.47). 



Using the result of Proposition 5.40 we get that at most 9 iterations are needed to 
compute the fixed point present in the analysis of the factorial statement. Since we 
know that already the first iterand will equal the fixed point one may ask whether 
one can obtain an even better bound on the number of iterations. The following 
exercise shows that the quadratic upper bound can be replaced by a linear upper 
bound: 

Exercise 5.49 ** Show that for each statement while b do S of While we have 

VS X [while b do Sj = H k JL 

where Eh — condp^-BxI^], hoVSxlSJ, id), k = m+1, and m is the cardinality 
of the set X = FV(while b do S). □ 

For the factorial statement this result will give that at most 3 iterations are 
needed to determine the fixed point. The next exercise shows that this is almost 
the best upper bound we can hope for: 

Exercise 5.50 * Show that for each m > 1 there is a statement while b do S of 
While such that 

VS X [while bdo Sj^ E k ±_ 

where Eh — condp^BxIfr], hoVSxlSJ, id), k = m— 1, and m is the cardinality 
of the set X = FV(while b do S). □ 



Chapter 6 

Axiomatic Program Verification 



The kinds of semantics we have seen so far specify the meaning of programs al- 
though they may also be used to prove that given programs possess certain proper- 
ties. We may distinguish between several classes of properties: partial correctness 
properties are properties expressing that if a given program terminates then there 
will be a certain relationship between the initial and the final values of the vari- 
ables. Thus a partial correctness property of a program need not ensure that it 
terminates. This is contrary to total correctness properties which express that the 
program will terminate and that there will be a certain relationship between the 
initial and the final values of the variables. Thus we have 

partial correctness + termination = total correctness 

Yet another class of properties is concerned with the resources used when executing 
the program. An example is the time used to execute the program on a particular 
machine. 

6.1 Direct proofs of program correctness 

In this section we shall give some examples that prove partial correctness of state- 
ments based directly on the operational and denotational semantics. We shall 
prove that the factorial statement 

y := 1; while -i(x=l) do (y := y*x; x := x— 1) 

is partially correct, that is if the statement terminates then the final value of y 
will be the factorial of the initial value of x. 

Natural semantics 

Using natural semantics the partial correctness of the factorial statement can be 
formalized as follows: 
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For all states s and s', if 

(y := 1; while -i(x=l) do (y := y*x; x := x— 1), s) — > s' 

then s' y = (s x)! and s x > 

This is indeed a partial correctness property because the statement does not ter- 
minate if the initial value s x of x is non-positive. 
The proof proceeds in three stages: 

Stage 1: We prove that the body of the while loop satisfies: 
if (y := y*x; x := x— 1, s) — > s" and s" x > 
then (s y) ★ (s x)! = (s" y) * (s" x)! and s x > 

Stage 2: We prove that the while loop satisfies: 

if (while -i(x=l) do (y := y*x; x := x— 1), s) — > s" 
then (s y) * (s x)! = s" y and s" x = 1 and s x > 

Stage 3: We prove the partial correctness property for the complete program: 
if (y := 1; while ->(x=l) do (y := y*x; x := x-l), s) ->■ s' 

I \ 

then s' y = (s x)! and s x > 

In each of the three stages the derivation tree of the given transition is inspected 
in order to prove the property. 

In the first stage we consider the transition 

(y := y*x; x := x-l, s) ->■ s" 

According to [comp ns ] there will be transitions 

(y := y*x, s) — > s' and (x := x— 1, s') — > s" 

for some s'. From the axiom [ass ns ] we then get that s' — <s[yM-^4|y*x],s] and that 
s" = s'[xi— hAfx— Combining these results we have 

s" = s[yh^(s y)*(a x)][x^(s x)-l] 

Assuming that s" x > we can then calculate 

(a" y) * (a" x)! = ((a y) * (a x)) * ((a x)-l)! = (s y) * (a x)! 

and since 5 x = (5" x) + 1 this shows that (*) does indeed hold. 

In the second stage we proceed by induction on the shape of the derivation tree 

for 

(while -i(x=l) do (y := y*x; x := x— 1), s) — > s' 
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One of two axioms and rules could have been used to construct this derivation. 
If [while^ s ] has been used then s' — s and B[-i(x=l)]s = ff. This means that 
s' x = 1 and since 1! = 1 we get the required (s y) * (s x)! — s y and s x > 0. 
This proves (**). 

Next assume that [while" s ] is used to construct the derivation. Then it must 
be the case that #|-i(x=l)]s = tt and 

(y := y*x; x := x-1, s) ->■ s" 

and 

(while -i(x=l) do (y := y*x; x := x— 1), s") — »■ s' 

for some state s". The induction hypothesis applied to the latter derivation gives 
that 

(s" y) * (s" x)! = s' y and s' x = 1 and s" x > 
From (*) we get that 

(s y) * (s x)! = (s" y) * (s" x)! and s x > 
Putting these results together we get 

(s y) * (s x)! = s' y and 5' x = 1 and 5 x > 

This proves (**) and thereby the second stage of the proof is completed. 
Finally, consider the third stage of the proof and the derivation 

(y := 1; while -i(x=l) do (y := y*x; x := x— 1), s) — > s' 

According to [comp ns ] there will be a state s" such that 

(y := 1, s) -> s" 

and 

(while -i(x=l) do (y := y*x; x := x— 1), s") — > s' 

From axiom [ass ns ] we see that s" — s[yi->l] and from (**) we get that s" x > 
and therefore s x > 0. Hence (a)! = (s" y) ★ (s" x)! holds and using (**) we get 

(s x)! = (s" y) * (s" x)! = s' y 

as required. This proves the partial correctness of the factorial statement. 

Exercise 6.1 Use the natural semantics to prove the partial correctness of the 
statement 
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z := 0; while y<x do (z := z+1; x := x— y) 

that is prove that if the statement terminates in s' when executed from a state s 
with s x > and s y > 0, then s' z = (s x) div (s y) and 5' x = (s x) mod (s y) 
where div is integer division and mod is the modulo operation. □ 

Exercise 6.2 Use the natural semantics to prove the following total correctness 
property for the factorial program: for all states s 

if s x > then there exists a state s' such that 

(y := 1; while -i(x=l) do (y := y*x; x := x— 1), s) — > s' 

and s' y = (s x)! □ 

Structural operational semantics 

The partial correctness of the factorial statement can also be established using the 
structural operational semantics. The property is then reformulated as: 

For all states s and s', if 

(y := 1; while -i(x=l) do (y := y*x; x := x— 1), s) =>* s' 

then s' y = (s x)! and s x > 

Again it is worthwhile to approach the proof in stages: 

Stage 1: We prove by induction on the length of derivation sequences that 
if (while -i(x=l) do (y := y*x; x := x— 1), s) =^ k s' 
then s' y = (s y) * (s x)! and s' x = 1 and s x > 

Stage 2: We prove that 

if (y := 1; while -i(x=l) do (y := y*x; x := x— 1), s) =>* s' 
then s' y = (s x)! and s x > 

Exercise 6.3 Complete the proof of stages 1 and 2. □ 
Denotational semantics 

We shall now use the denotational semantics to prove partial correctness properties 
of statements. The idea is to formulate the property as a predicate ip on the ccpo 
(State <— y State, C), that is 



ip: (State State) T 
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As an example, the partial correctness of the factorial statement will be written 
as 

Vvac(<s ds [y : = 1 ! while ^( x=1 ) do (y : = y* x ; x := x ~ 1 )l) = u 

where the predicate ipf ac is defined by 

^fac(g) = tt 
if and only if 

for all states s and s', if g s = s' then s' y = (s x)! and s x > 

A predicate ip: D — f T defined on a ccpo (D,\Z) is called an admissible predicate 
if and only if we have 

if ip d = tt for all d G F then V(U F) = tt 

for every chain Y m D. Thus if ip holds on all the elements of the chain then it 
also holds on the least upper bound of the chain. 

Example 6.4 Consider the predicate i^'jac defined on State <^-> State by 

i>fac(9) = 
if and only if 

for all states s and s', if g s = s' 
then s ! y = (s y) * (5 x)! and s x > 

Then i^'jac 1S an admissible predicate. To see this assume that Y is a chain in 
State <^-> State and assume that V'/ac 5 — tt for all g G F. We shall then prove 
that ip' fac (\JY) = tt, that is 

(UF) s = s' 
implies 

s' y — (s y) -k (s x)! and s x > 

From Lemma 4.25 we have graph(|J Y) — |J{ graph(^) | g G F }. We have assumed 
that (LJF) s = 5' so F cannot be empty and (5, s') G graph(g) for some g G F. 
But then 

5' y = (5 y) * (5 x)! and 5 x > 

as ip'f ac g — tt for all ^ G F. This proves that ip'f ac is an admissible predicate. □ 

For admissible predicates we have the following induction principle called fixed 
point induction: 
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Theorem 6.5 Let (D,\Z) be a ccpo and let /: D — > D be a continuous function 
and let ip be an admissible predicate on D. If for all d 6 D 

ip d = tt implies ip(f d) = tt 

then V(FIX /) = tt. 

Proof: We shall first note that 
ip ± = tt 

holds by admissibility of ip (applied to the chain Y = 0). By induction on n we 
can then show that 

V<(/ n -L) = tt 

using the assumptions of the theorem. By admissibility of ip (applied to the chain 
Y = { f n JL | n > }) we then have 

iP(F1X /) = tt 

This completes the proof. □ 

We are now in a position where we can prove the partial correctness of the 
factorial statement. The first observation is that 

<Sds[y := 1; while -i(x=l) do (y := y*x; x := x— = s' 

if and only if 

<S ds [while ^(x=l) do (y := y*x; x := x-l)](s[yM>l]) = s' 

Thus it is sufficient to prove that 

V/ /QC (S ds [while -,(x=l) do (y := y^x; x := x-l)]) = tt (*) 
(where ip'f ac is defined in Example 6.4) as this will imply that 

^/ac(<5 ds [y := 1; while ^(x=l) do (y := y*x; x := x-l)]) = tt 

We shall now reformulate (*) slightly to bring ourselves in a position where we 
can use fixed point induction. Using the definition of S^s in Table 4.1 we have 

<S ds [while -n(x=l) do (y := y*x; x := x-l)] = FIX F 

where the functional F is defined by 

F g — cond(#Hx=l)], g o £ ds [y := y*x; x := x-l], id) 
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Using the semantic equations defining <S ds we can rewrite this definition as 



We have already seen that F is a continuous function (for example in the proof 
of Proposition 4.47) and from Example 6.4 we have that V/ ac is an admissible 
predicate. Thus we see from Theorem 6.5 that (*) follows if we show that 

iP'fac 9 = tt implies ip' fac {F g) = tt 
To prove this implication assume that ip'f ac g — tt, that is for all states s and s' 

if g s = s' then s' y = (s y) * (s x)! and s x > 
We shall prove that ip'f ac (F g) = tt, that is for all states s and s' 

if (F g) s — s' then s' y = (s y) * (s x)! and s x > 

Inspecting the definition of F we see that there are two cases. First assume that 
s x = 1. Then (F g) s — s and clearly s y = (s y) * (s x)! and s x > 0. Next 
assume that sx/1. Then 

(F s = g(s[j^(s j)-k(s x)][x^(s x)-l]) 
From the assumptions about g we then get that 

s' y = ((s y)*(s x)) * ((5 x)-l)! and (s x)-l > 
so that the desired result 

s ' y = i s y) * ( 5 x )' an d 5 x > 

follows. 

Exercise 6.6 Repeat Exercise 6.1 using the denotational semantics. □ 

6.2 Partial correctness assertions 

One may argue that the above proofs are too detailed to be practically useful; the 
reason is that they are too closely connected with the semantics of the program- 
ming language. One may therefore want to capture the essential properties of the 
various constructs so that it would be less demanding to conduct proofs about 
given programs. Of course the choice of "essential properties" will determine the 
sort of properties that we may accomplish proving. In this section we shall be 
interested in partial correctness properties and therefore the "essential properties" 
of the various constructs will not include termination. 

The idea is to specify properties of programs as assertions, or claims, about 
them. An assertion is a triple of the form 
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{ P } S { Q} 

where S is a statement and P and Q are predicates. Here P is called the precondi- 
tion and Q is called the postcondition. Intuitively, the meaning of { P } S { Q } 
is that 

if P holds in the initial state, and 

if the execution of S terminates when started in that state, 
then Q will hold in the state in which S halts 

Note that for { P } S { Q } to hold we do not require that S halts when started 
in states satisfying P — merely that if it does halt then Q holds in the final state. 



Logical variables 

As an example we may write 

{ x=n } y := 1; while -i(x=l) do (y := x*y; x := x— 1) { y=n! A n>0 } 

to express that if the value of x is equal to the value of n before the factorial 
program is executed then the value of y will be equal to the factorial of the value 
of n after the execution of the program has terminated (if indeed it terminates). 
Here n is a special variable called a logical variable and these logical variables 
must not appear in any statement considered. The role of these variables is to 
"remember" the initial values of the program variables. Note that if we replace 
the postcondition y=n! A n>0 by the new postcondition y=x! A x>0 then the 
assertion above will express a relationship between the final value of y and the 
final value of x and this is not what we want. The use of logical variables solves 
the problem because it allows us to refer to initial values of variables. 
We shall thus distinguish between two kinds of variables: 

• program variables, and 

• logical variables. 

The states will determine the values of both kinds of variables and since logical 
variables do not occur in programs their values will always be the same. In case 
of the factorial program we know that the value of n is the same in the initial 
state and in the final state. The precondition x = n expresses that n has the same 
value as x in the initial state. Since the program will not change the value of n the 
postcondition y = n! will express that the final value of y is equal to the factorial 
of the initial value of x. 
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The assertion language 

There are two approaches concerning how to specify the preconditions and post- 
conditions of the assertions: 

• the intensional approach, versus 

• the extensional approach. 

In the intensional approach the idea is to introduce an explicit language called an 
assertion language and then the conditions will be formulae of that language. This 
assertion language is in general much more powerful than the boolean expressions, 
Bexp, introduced in Chapter 1. In fact the assertion language has to be very 
powerful indeed in order to be able to express all the preconditions and postcon- 
ditions we may be interested in; we shall return to this in the next section. The 
approach we shall follow is the extensional approach and it is a kind of shortcut. 
The idea is that the conditions are predicates, that is functions in State — > T. 
Thus the meaning of { P } S { Q } may be reformulated as saying that if P holds 
on a state s and if S executed from state s results in the state s' then Q holds on 
s' . We can write any predicates we like and therefore the expressiveness problem 
mentioned above does not arise. 

Each boolean expression b defines a predicate B\b\. We shall feel free to let 
b include logical variables as well as program variables so the precondition x = n 
used above is an example of a boolean expression. To ease the readability, we 
introduce the following notation 



Pi A P 2 


for 


P where P s — 


(Pi s) and (P 2 s) 


Pi V P 2 


for 


P where P s — 


(Pi s) or (P 2 s) 


^P 


for 


P' where P' s = 


- AP s) 


P[xi->A[a\] 


for 


P' where P' s = 


-- P {s[x^A[a]s]) 


Pi => P2 


for 


Vs e State: P 1 


s implies P 2 s 



When it is convenient, but not when defining formal inference rules, we shall 
allow to dispense with B\- ■ •] and A\- ■ •] inside square brackets as well as within 
preconditions and postconditions. 

Exercise 6.7 Show that 

• B[6[a;i-»a]] = S[6][zi-h4[a]] for all b and a, 

• B[h A b 2 j = A B[b 2 ] for all b 1 and b 2 , and 



= -,£[6] for all b. 



□ 
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lassJ 


{ Pb^^Jal] } x := a { P } 

L L U. JJJ J L J 


[skip p ] 


{ P } skip { P } 


[comp p ] 


{ P j t>i { Q j, { Q \ b 2 { n } 


r pi c. or d i 


[if P ] 




{ P } if b then 5i else S 2 { Q } 


[while p ] 


I #[oJ A P } b { P } 


{ P } while bdo S { ^B[b\ A P } 


[consp] 


{ } S { Q' } 

if P P' and Q' ^ Q 

{P}S{Q} 



Table 6.1: Axiomatic system for partial correctness 



The inference system 

The partial correctness assertions will be specified by an inference system consist- 
ing of a set of axioms and rules. The formulae of the inference system have the 
form 

{ P } S { Q} 

where S is a statement in the language While and P and Q are predicates. The 
axioms and rules are summarized in Table 6.1 and will be explained below. The 
inference system specifies an axiomatic semantics for While. 
The axiom for assignment statements is 

{ P[x^A{a\] } x:=a{P} 

This axiom assumes that the execution of £ := a starts in a state s that satisfies 
P[iH>^4[a]], that is in a state s where «[a:H>i[a]s] satisfies P. The axiom expresses 
that if the execution of £ := a terminates (which will always be the case) then the 
final state will satisfy P. From the earlier definitions of the semantics of While 
we know that the final state will be s[x\- >A\a\s\ so it is easy to see that the axiom 
is plausible. 

For skip the axiom is 

{ P } skip { P } 

Thus if P holds before skip is executed then it also holds afterwards. This is 
clearly plausible as skip does nothing. 
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Axioms [assp] and [skip p ] are really axiom schemes generating separate axioms 
for each choice of predicate P. The meaning of the remaining constructs are given 
by rules of inference rather than axiom schemes. Each such rule specifies a way 
of deducing an assertion about a compound construct from assertions about its 
constituents. For composition the rule is: 



This says that if P holds prior to the execution of Si, S2 and if the execution 
terminates then we can conclude that R holds in the final state provided that 
there is a predicate Q for which we can deduce that 

• if Si is executed from a state where P holds and if it terminates then Q will 
hold for the final state, and that 

• if S2 is executed from a state where Q holds and if it terminates then R will 
hold for the final state. 

The rule for the conditional is 



The rule says that if if b then Si else 52 is executed from a state where P holds 
and if it terminates, then Q will hold for the final state provided that we can 
deduce that 

• if Si is executed from a state where P and b hold and if it terminates then 
Q holds on the final state, and that 

• if 62 is executed from a state where P and -16 hold and if it terminates then 
Q holds on the final state. 

The rule for the iterative statement is 



The predicate P is called an invariant for the while-loop and the idea is that it 
will hold before and after each execution of the body S of the loop. The rule says 
that if additionally b is true before each execution of the body of the loop then -16 
will be true when the execution of the while-loop has terminated. 

To complete the inference system we need one more rule of inference 



{P}Si{Q}, {Q}S 2 {R} 
{P}Si;S 2 {R} 



{ B{b] A P } Si { Q }, { -ng[6] A P } S 2 { Q } 
{ P } if b then Si else S 2 { Q } 



{ B{b] A P } S { P } 



{ P } while bdo S { A P } 



{ P' } S { Q' } 
{P}S{Q} 



if P => P' and Q' => Q 
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This rule says that we can strengthen the precondition P' and weaken the post- 
condition Q' . This rule is often called the rule of consequence. 

Note that Table 6.1 specifies a set of axioms and rules just as the tables defining 
the operational semantics in Chapter 2. The analogue of a derivation tree will now 
be called an inference tree since it shows how to infer that a certain property holds. 
Thus the leaves of an inference tree will be instances of axioms and the internal 
nodes will correspond to instances of rules. We shall say that the inference tree 
gives a proof of the property expressed by its root. We shall write 

\- P {P}S{Q} 

for the provability of the assertion { P } S { Q }. An inference tree is called 
simple if it is an instance of one of the axioms and otherwise it is called composite. 

Example 6.8 Consider the statement while true do skip. From [skip p ] we have 
(omitting the B[- • •]) 

hp { true } skip { true } 
Since (true A true) =>• true we can apply the rule of consequence [cons p ] and get 

hp { true A true } skip { true } 
Hence by the rule [while p ] we get 

hp { true } while true do skip { -itrue A true } 
We have that -itrue A true =>• true so by applying [cons p ] once more we get 

hp { true } while true do skip { true } 
The inference above can be summarized by the following inference tree: 
{ true } skip { true } 



{ true A true } skip { true } 



{ true } while true do skip { -itrue A true } 



{ true } while true do skip { true } 

It is now easy to see that we cannot claim that { P } S { Q } means that S 
will terminate in a state satisfying Q when it is started in a state satisfying P. 
For the assertion { true } while true do skip { true } this reading would mean 
that the program would always terminate and clearly this is not the case. □ 
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Example 6.9 To illustrate the use of the axiomatic semantics for verification we 
shall prove the assertion 



y := 1; while -i(x=l) do (y := y*x; x := x— 1) 
{y = n! An>0} 

where, for the sake of readability, we write y = n! A n > for the predicate 

P where P s = (s y = (s n)! A s n > 0) 

The inference of this assertion proceeds in a number of stages. First we define the 
predicate INV that is going to be the invariant of the while-loop: 

INV s = (s x > implies ((s y) * (s x)! = (s n)! and s n > s x)) 



n} 



We shall then consider the body of the loop. Using [ass p ] we get 



h p { INV[x^x-l] } x := x-1 { INV } 



Similarly, we get 



h p { (/W[x^x-l])[y^y*x] } y := y ★ x { /W[x^x-l] } 



We can now apply the rule [comp p ] to the two assertions above and get 



hp { (7W[x^x-l])[y^y*x] } y := y * x; x : 



x-1 { INV } 



It is easy to verify that 



Hx=l) A INV) (/W[x^x-l])[y^y*x] 



so using the rule [cons p ] we get 



hp { -n(x = 1) A INV } y := y * x; x := x 



1 { INV } 



We are now in a position to use the rule [while p ] and get 




1) 



Clearly we have 



^(^(x = 1)) A INV =^y = n! An>0 
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so applying rule [cons p ] we get 

hp { INV } while -i(x=l) do (y := y*x; x := x-l) { y = n! A n > } 
We shall now apply the axiom [ass p ] to the statement y := 1 and get 

h p { INV[j^l] } y := 1 { INV } 
Using that 

x = n INV[jt-H] 
together with [cons p ] we get 

h p { x = n } y := 1 { INV } 

Finally, we can use the rule [comp p ] and get 

hp { x = n } 

y := 1; while -i(x=l) do (y := y*x; x := x— 1) 
{y = n! An>0} 

as required. □ 

Exercise 6.10 Specify a formula expressing the partial correctness property of 
the program of Exercise 6.1. Construct an inference tree giving a proof of this 
property using the inference system of Table 6.1. □ 

Exercise 6.11 Suggest an inference rule for repeat S until b. You are not 
allowed to rely on the existence of a while-construct in the language. □ 

Exercise 6.12 Suggest an inference rule for for x :— Oi to a 2 do S. You are not 
allowed to rely on the existence of a while-construct in the language. □ 

Properties of the semantics 

In the operational and denotational semantics we defined a notion of two programs 
being semantically equivalent. We can define a similar notion for the axiomatic 
semantics: Two programs S\ and S2 are provably equivalent according to the 
axiomatic semantics of Table 6.1 if for all preconditions P and postconditions Q 
we have 

U { P } Si { Q } if and only if h p { P } S 2 { Q } 

Exercise 6.13 Show that the following statements of While are provably equiv- 
alent in the above sense: 
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• S; skip and S 

• Si, (S 2 ; S 3 ) and (Si, S 2 ); S 3 □ 

Proofs of properties of the axiomatic semantics will often proceed by induction 
on the shape of the inference tree: 



Induction on the Shape of Inference Trees 



Prove that the property holds for all the simple inference trees by showing 
that it holds for the axioms of the inference system. 

Prove that the property holds for all composite inference trees: For each 
rule assume that the property holds for its premises (this is called the 
induction hypothesis) and that the conditions of the rule are satisfied and 
then prove that it also holds for the conclusion of the rule. 



Exercise 6.14 ** Using the inference rule for repeat S until b given in Exercise 
6.11 show that repeat S until b is provably equivalent to S; while -16 do S. Hint: 
it is not too hard to show that what is provable about repeat S until b is also 
provable about S; while ->b do S. □ 

Exercise 6.15 Show that h p { P } S { true } for all statements S and properties 
P. ' ' " □ 



6.3 Soundness and completeness 

We shall now address the relationship between the inference system of Table 6.1 
and the operational and denotational semantics of the previous chapters. We shall 
prove that 

• the inference system is sound: if some partial correctness property can be 
proved using the inference system then it does indeed hold according to the 
semantics, and 

• the inference system is complete: if some partial correctness property does 
hold according to the semantics then we can also find a proof for it using the 
inference system. 

The completeness result can only be proved because we use the extensional ap- 
proach where preconditions and postconditions are arbitrary predicates. In the 
intensional approach we only have a weaker result; we shall return to this later in 
this section. 
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As the operational and denotational semantics are equivalent we only need to 
consider one of them here and we shall choose the natural semantics. The partial 
correctness assertion { P } S { Q } is said to be valid if and only if 

for all states s, if P s = tt and (S,s) — > s' for some s' then Q s' = tt 

and we shall write this as 

hAP}S{Q} 
The soundness property is then expressed by 

\~ P {P}S{Q} implies Hp { P } S { Q } 
and the completeness property is expressed by 

Hp { P } S { Q } implies \~ P {P}S{Q} 
We have 

Theorem 6.16 For all partial correctness assertions {P}S{Q}we have 
Hp { P } S { Q } if and only if \~ P {P}S{Q} 

It is customary to prove the soundness and completeness results separately. 
Soundness 

We shall first prove: 

Lemma 6.17 The inference system of Table 6.1 is sound, that is for every partial 
correctness formula {P}S{Q}we have 

U { P } S { Q } implies hp { P } S { Q } 

Proof: The proof is by induction on the shape of the inference tree used to infer 
hp { P } S { Q }. This amounts to nothing but a formalization of the intuitions 
we gave when introducing the axioms and rules. 

The case [ass p ]: We shall prove that the axiom is valid, so suppose that 
{x := a, s) — > s' 
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and (P[a;i— h4|a]]) s = tt. We shall then prove that P s' — tt. From [ass ns ] we get 
that s' = s[x\->Ala}s] and from (P[zi-hA|[a]]]) s — tt we get that P (s[x^-A{a]s]) 
= tt. Thus P s' — tt as was to be shown. 

The case [skip p ]: This case is immediate using the clause [skip ns ]. 
The case [comp p ]: We assume that 

Hp { P } S 1 { Q } and hp { Q } S 2 { R } 

and we have to prove that hp { P } S\\ S 2 { R }• So consider arbitrary states s 
and s" such that P s = tt and 

<5i;5 2 , s) s" 

From [comp ns ] we get that there is a state s' such that 

(S u s) -)• s' and (S 2 , s') -)• 5" 

From (5i, 5) ->■ 5', P 5 = tt and |= p { P } Si { Q } we get Q a' = tt. From 
(S2, s') — > 5", <5 5 ' = an d hp { Q } ^2 { P } it follows that P s" = tt as was 
to be shown. 

The case [if p ]: Assume that 

hp { B[b\ A P } S 1 { Q } and hp { ^B[b] A P } S 2 { Q } 

To prove \= p { P } if b then Si else 52 { Q } consider arbitrary states s and s' 
such that P s = tt and 

(if b then Si else S2, s) — > s' 

There are two cases. If = tt then we get (B{bJ A P) s — tt and from [if ns ] 

we have 

(Si, s) -> a' 

From the first assumption we therefore get Q s' = tt. If = ff the result 

follows in a similar way from the second assumption. 

The case [while p ]: Assume that 

hp { B[b] AP}S{P} 

To prove hp { P } while b do S { ~^B{bJ A P } consider arbitrary states s and 
s" such that P s — tt and 

(while b do S, s) ->■ 5" 
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and we shall show that (-J3J6JA.P) s" — tt. We shall now proceed by induction on 
the shape of the derivation tree in the natural semantics. One of two cases apply. 
If #[6]s = ff then s" — s according to [while„ s ] and clearly (-ijE?[6] A P) s" — tt 
as required. Next consider the case where = tt and 

(S, s) ->■ s' and (while b do S, s') ->■ s" 

for some state s'. Thus (B{bJ A P) s = tt and we can then apply the assump- 
tion ^ p { B[b] A P } S { P } and get that P s' = tt. The induction hypothe- 
sis can now be applied to the derivation (while b do S, s') — > s" and gives that 
(-!#[&] A P) s" — tt. This completes the proof of this case. 

The case [cons p ]: Suppose that 

hp { P' } S { Q' } and P => P' and Q' => Q 
To prove \= P { P } S { Q } consider states s and s' such that P s — tt and 

{S, s) -> s' 

Since P s — tt and P P' we also have P' s = tt and the assumption then gives 
us that Q' s' — tt. From Q' =^> Q we therefore get Q s' = tt as required. □ 



Exercise 6.18 Show that the inference rule for repeat S until b suggested in 
Exercise 6.11 preserves validity. Argue that this means that the entire proof system 
consisting of the axioms and rules of Table 6.1 together with the rule of Exercise 
6.11 is sound. □ 

Exercise 6.19 Define |=' { P } S { Q } to mean that 

for all states s such that P s = tt there exists a state s' such that 
Q s' = tt and (5, s) ->■ s' 

Show that it is not the case that \~p{P}S{Q} implies \='{P}S{Q} and 
conclude that the proof system of Table 6.1 cannot be sound with respect to this 
definition of validity. □ 

Completeness (in the extensional approach) 

Before turning to the proof of the completeness result we shall consider a special 
predicate wlp(iS', Q) defined for each statement S and predicate Q: 

wlp(5', Q) s = tt 



if and only if for all states s', 
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if {S, s) ->■ s' then Q s' = tt 
The predicate is called the weakest liberal precondition for <5 and it satisfies: 

Fact 6.20 For every statement S and predicate Q we have 

. Hp { wlp(5, Q) } S { Q } (*) 
• if Hp { P } S { Q } then P =>- wlp(5, Q) (**) 

meaning that wlp(iS', Q) is the weakest possible precondition for S and Q. 



Proof: To verify that (*) holds let s and s' be states such that {S, s) — > s' 
and wlp(iS', Q) s = tt. From the definition of wlp(iS', Q) we get that Q s' — tt 
as required. To verify that (**) holds assume that \=p { P } S { Q } and let 
P s — tt. If (S, s) — > s' then Q s' — tt (because \= p { P } S { Q }) so clearly 
wlp(S,Q) a = tt. □ 

Exercise 6.21 Prove that the predicate INV of Example 6.9 satisfies 

INV = wlp(while -i(x=l) do (y := y*x; x := x-1), y = n! A n > 0) □ 

Exercise 6.22 Another interesting predicate called the strongest postcondition 
for S and P can be defined by 

sp(P, S) s' = tt 

if and only if 

there exists s such that {S, s) — > s' and P s = tt 

Prove that 

. hp { P } S { sp(P, S) } 

• if hp { P } S { Q } then sp(P, S) => Q 

Thus sp(P, S) is the strongest possible postcondition for P and S. □ 



Lemma 6.23 The inference system of Table 6.1 is complete, that is for every 
partial correctness formula {P}S{Q}we have 

Hp { P } S { Q } implies \~p{P}S{Q} 
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(*) 



Then Fact 6.20 gives that 



P wlp(S,Q) 
so that (*) and [cons p ] give 
h p { P } S { <? } 



as required. 

To prove (*) we proceed by structural induction on the statement 5*. 
The case x :— a: Based on the natural semantics it is easy to verify that 

wlp(z := a, Q) = Q[xh^A{aJ] 

so the result follows directly from [ass p ]. 

The case skip: Since wlp(skip, Q) — Q the result follows from [skip p ]. 
The case Si,S2- The induction hypothesis applied to Si and S2 gives 



as then [cons p ] will give the required proof in the inference system. So assume that 
wlp(iS , i;iS , 2 , Q) s = tt and we shall show that wlp(iS'i, wlp(iS , 2 , Q)) s — tt. This is 
obvious unless there is a state s' such that {Si, s) — > s' and then we must prove 
that wlp(iS , 2 , Q) s' = tt. However, this is obvious too unless there is a state s" 
such that {S2, s') — > s" and then we must prove that Q s" = tt. But by [comp ns ] 
we have {Si,S2, s) — > s" so that Q s" = tt follows from w\p(Si,S2, Q) s = tt. 

The case if b then Si else S2 '■ The induction hypothesis applied to Si and S2 
gives 



h p { wlp(5 2j Q) } S 2 { Q } 



and 




We shall now prove that 



w\p(Si;S 2 , Q) wlp(,S , i, wlp(,S , 2, Q)) 
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h p { wlp(5i, Q) } 5i { Q } and h p { wlp(5 2 , Q) } S 2 { Q } 



Define the predicate P by 



P = (B{b\ A wlp(5i, Q)) V ^B{bj A wlp(S 2 , Q)) 



Then we have 

(B\b\ A P) => wlp(5i, Q) and A P) =>• wlp(5 2 , Q) 

so [consp] can be applied twice and gives 

hp { B[b\ A P } S 1 { Q } and hp { ^B{b] A P } S 2 { Q } 
Using [if p ] we therefore get 

hp { P } if b then Si else S 2 { Q } 
To see that this is the desired result it suffices to show that 

wlp(if b then Si else 5* 2 , Q) =^ P 

and this is straightforward by cases on the value of b. 
The case while b do S: Define the predicate P by 

P = wlp(while b do S, Q) 

We first show that 



To verify (**) let s be such that A P) s = tt. Then it must be the case 

that (while b do S, s) — > s so we have Q s — tt. To verify (***) let s be such 
that (B{bJ A P) s = tt and we shall show that wlp(iS',P) s — tt. This is obvious 
unless there is a state s' such that {S, s) — > s' in which case we shall prove that 
P s' — tt. We have two cases. First we assume that (while b do S, s') — > s" for 
some s" . Then [while" s ] gives us that (while b do S, s) — > s" and since P s — 
tt we get that Q s" — tt using Fact 6.20. But this means that P s' — tt as was 
required. In the second case we assume that (while b do 5 1 , s') — > s" does not 
hold for any state s" . But this means that P s' — tt holds vacuously and we have 
finished the proof of (***). 

The induction hypothesis applied to the body S of the while-loop gives 



H?[6] AP)^Q 
(B{b] A P) => wlp(5,P) 




hp { w\p(S,P) }S{P} 



and using (***) together with [cons p ] we get 
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h p { B[b] A P } S { P } 
We can now apply the rule [while p ] and get 

h p { P } while b do S { A P } 

Finally, we use (**) together with [cons p ] and get 

h p { P } while b do S { Q } 
as required. □ 

Exercise 6.24 Prove that the inference system for the while-language extended 
with repeat 5* until b as in Exercise 6.11 is complete. (If not you should improve 
your rule for repeat S until b.) □ 

Exercise 6.25 * Prove the completeness of the inference system of Table 6.1 
using the strongest postconditions of Exercise 6.22 rather than the weakest liberal 
preconditions as used in the proof of Lemma 6.23. □ 

Exercise 6.26 Define a notion of validity based on the denotational semantics 
of Chapter 4 and prove the soundness of the inference system of Table 6.1 using 
this definition, that is without using the equivalence between the denotational 
semantics and the operational semantics. □ 

Exercise 6.27 Use the definition of validity of Exercise 6.26 and prove the com- 
pleteness of the inference system of Table 6.1. □ 



Expressiveness problems (in the intensional approach) 

So far we have only considered the extensional approach where the preconditions 
and postconditions of the formulae are predicates. In the intensional approach they 
are formulae of some assertion language C The axioms and rules of the inference 
system will be as in Table 6.1, the only difference being that the preconditions 
and postconditions are formulae of C and that operations such as P[i^[a]], 
Pi A P2 and Pi =>- P 2 are operations on formulae of L. 

It will be natural to let C include the boolean expressions of While. The 
soundness proof of Lemma 6.17 then carries directly over to the intensional ap- 
proach. Unfortunately, this is not the case for the completeness proof of Lemma 
6.23. The reason is that the predicates wlp(iS', Q) used as preconditions now have 
to be represented as formulae of C and that this may not be possible. 

To illustrate the problems let S be a statement, for example a universal program 
in the sense of recursion theory, that has an undecidable Halting problem. Further, 
suppose that C only contains the boolean expressions of While. Finally, assume 
that there is a formula 5$ of £ such that for all states s 
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B[6s] s = tt if and only if wlp^, false) s — tt 
Then also ~^bs is a formula of C. We have 

B[&s] s = tt if and only if the computation of S on s loops 
and hence 

£[-i&s] s = tt if and only if the computation of S on s terminates 

We now have a contradiction: the assumptions about S ensure that Bj-ifis] must 
be an undecidable function; on the other hand Table 1.2 suggests an obvious 
algorithm for evaluating #[-165]. Hence our assumption about the existence of bs 
must be mistaken. Consequently we cannot mimic the proof of Lemma 6.23. 

The obvious remedy is to extend £ to be a much more powerful language that 
allows quantification as well. A central concept is that C must be expressive with 
respect to While and its semantics, and one then shows that Table 6.1 is relatively 
complete (in the sense of Cook). It is beyond the scope of this book to go deeper 
into these matters but we provide references in Chapter 7. 

6.4 Extensions of the axiomatic system 

In this section we shall consider two extensions of the inference system for par- 
tial correctness assertions. The first extension shows how the approach can be 
modified to prove total correctness assertions thereby allowing us to reason about 
termination properties. In the second extension we consider how to extend the 
inference systems to more language constructs, in particular recursive procedures. 

Total correctness assertions 

We shall now consider formulae of the form 

{P}S{HQ} 
The idea is that 

if the precondition P is fulfilled 

then S is guaranteed to terminate (as recorded by the symbol JJ-) 
and the final state will satisfy the postcondition Q. 

This is formalized by defining validity of {P}S{i)-Q} by 

H{P}S{tlQ} 
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fasstl 

L J 


{ P[x^4[a]l } x := a { $ P } 

LL U_ JJJ J Lv J 


[skip t ] 


{ P } skip { ^ P } 


[compt] 






[ift] 


{ B[b] AP}5i{|Q}, { -.B[6] A P } S 2 { $ Q } 


{ P } if b then Si else S 2 { Q } 


[while t ] 


{ P(z+1) } S { ^ P(z) } 


{ 3z.P(z) } while 6 do £ { ^ P(0) } 
where P(z+1) =^ M61, P(0) ^ -.fiffil 

and z ranges over natural numbers (that is z>0) 


[cons t ] 


{ P' } S { i}, Q' } 

where P ^ P' and Q' Q 

{P}S{HQ} 



Table 6.2: Axiomatic system for total correctness 



if and only if 

for all states s, if P s = tt then there exists s' such that 

Q a' = tt and (5, s) ->■ a' 

The inference system for total correctness assertions is very similar to that for 
partial correctness assertions, the only difference being that the rule for the while- 
construct has changed. The complete set of axioms and rules is given in Table 6.2. 
We shall write 

h { P } s { Q } 

if there exists an inference tree with the formula {P}S{i)-Q} as root, that is 
if the formula is provably in the inference system. 

In the rule [while t ] we use a parameterized family P(z) of predicates for the 
invariant. The idea is that z is the number of unfoldings of the while-loop that will 
be necessary. So if the while-loop does not have to be unfolded at all then P(0) 
holds and it must imply that b is false. If the while-loop has to be unfolded z+1 
times then P(z+1) holds and b must hold before the body of the loop is executed; 
then P(z) will hold afterwards so that we have decreased the total number of 
times the loop remains to be unfolded. The precondition of the conclusion of the 
rule expresses that there exists a bound on the number of times the loop has to be 
unfolded and the postcondition expresses that when the while-loop has terminated 
then no more unfoldings are necessary. 
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Example 6.28 The total correctness of the factorial statement can be expressed 
by the following assertion: 

{x>0Ax=n} 

y := 1; while -i(x=l) do (y := y*x; x := x— 1) 

{ 4 7 = n! } 

where y = n! is an abbreviation for the predicate 

P where P s — (s y = (s n)!) 

In addition to expressing that the final value of y is the factorial of the initial 
value of x the assertion also expresses that the program does indeed terminate on 
all states satisfying the precondition. The inference of this assertion proceeds in 
a number of stages. First we define the predicate INV(z) that is going to be the 
invariant of the while-loop 

INV(z) s — (s x > and (s y) * (s x)! = (s n)! and s x = z + 1) 
We shall first consider the body of the loop. Using [ass t ] we get 

h { /W(z)[x^x-l] } x := x-1 { ^ INV(z) } 
Similarly, we get 

h { (/W(z)[x^x-l])[y^y*x] } y := y * x { ^ /W(z)[x^x-l] } 
We can now apply the rule [comp t ] to the two assertions above and get 

h { (/W(z)[x^x-l])[y^y*x] } y := y * x; x := x-1 { ^ INV(z) } 
It is easy to verify that 

INV (z+1) => (/W(z)[x^x-l])[y^y*x] 
so using the rule [cons t ] we get 

h { INV (z+1) } y := y * x; x := x-1 { ^ INV (z) } 

It is straightforward to verify that 

INV(0) => -.(-.(x=l)), and 
INV (z+1) => -(x=l) 

Therefore we can use the rule [while t ] and get 

K { 3z.INV(z) } while ^(x=l) do (y := y^x; x := x-1) { ^ INV(0) } 
We shall now apply the axiom [ass t ] to the statement y := 1 and get 
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K { (3z./W(z))[y^l] } y := 1 { ^ 3z./W(z) } 
so using [comp t ] we get 

h { (3z./W(z))[y^l] } 

y := 1; while -i(x=l) do (y : = y*x; x := x— 1) 
{ ^ INV(0) } 
Clearly we have 

x>0Ax = n=> (3z./W(z))[yM>l], and 
INV(0) => y = n! 
so applying rule [cons t ] we get 
h t {x>0Ax = n} 

y := 1; while -i(x=l) do (y := y*x; x := x— 1) 
{ 4 7 = n! } 

as required. □ 

Exercise 6.29 Suggest a total correctness inference rule for repeat S until b. 
You are not allowed to rely on the existence of a while-construct in the program- 
ming language. □ 



Lemma 6.30 The total correctness system of Table 6.2 is sound, that is for every 
total correctness formula {P}S{i}-Q}we have 

\~t{P}S{l),Q} implies H{P}S{HQ} 

Proof: The proof proceeds by induction on the shape of the inference tree just as 
in the proof of Lemma 6.17. 

The case [ass t ]: We shall prove that the axiom is valid, so assume that s is such 
that (P[x\- ►AJa]]) s — tt and let s' — s[x^-A{a}s]. Then [ass ns ] gives 

{x :— a, s) — > s' 

and from hAfa]]) s = tt we get P s' — tt as was to be shown. 

The case [skip t ]: This case is immediate. 

The case [comp t ]: We assume that 

h { P } Si { ^ Q }, and (*) 
h { Q } S 2 { V R } (**) 

and we have to prove that |= t { P } S\\ S 2 { JJ- R }• So let s be such that P s = tt. 
From (*) we get that there exists a state s' such that Q s' — tt and 
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(S u s) -> s' 

Since Q s' — tt we get from (**) that there exists a state s" such that P 5" = tt 
and 

(S 2 , s') -> s" 

Using [comp ns ] we therefore get 

(Si, S 2 , s) -> ^" 

and since P s" — tt we have finished this case. 
The case [if t ]: Assume that 

h { B[b] A P } Si { Q }, and (*) 

h { ^B[b] A P } S 2 { J| Q } 

To prove j= t { P } if b then Si else S 2 { JJ- <5 } consider a state 5 such that 
P s = tt. We have two cases. If B[6]a = tt then (B{bj A P) s = tt and from (*) 
we get that there is a state 5' such that Q s' = tt and 

a) -> ^ 

From [if ns ] we then get 

(if b then 5i else $2, s) — > 5' 

as was to be proved. If = fF the result follows in a similar way from the 

second assumption. 

The case [while t ]: Assume that 

h { P(*+l) } S { Jj. P(z) }, (*) 
P(z+1) => B[b], and 
P(0) =► -,B[6] 

To prove |= t { 3z.P(z) } while 6 do 5 { JJ- P(0) } it is sufficient to prove that for 
all natural numbers z 

if P(z) s — tt then there exists a state s' such that 

P(0) 5' = tt and (while 6 do 5, 5) ->■ 5' 

So consider a state 5 such that P(z) 5 = tt. The proof is now by numerical 
induction on z. 

First assume that z = 0. The assumption P(0) =>• gives that = 

ff and from [while^J we get 

(while b do S, s) — > s 
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Since P(0) s = tt this proves the base case. 

For the induction step assume that (**) holds for all states satisfying P(z) and 
that P(z+1) s — tt. From (*) we get that there is a state s' such that P(z) s' — 
tt and 

{S, s) s' 

The numerical induction hypothesis applied to s' gives that there is some state s" 
such that P(0) s" = tt and 

(while b do S, s') ->• s" 

Furthermore, the assumption P(z+1) B\b\ gives = tt. We can therefore 

apply [while**] and get that 

(while b do S, s) ->■ s" 

Since P(0) s" — tt this completes the proof of (**). 
The case [cons t ]: Suppose that 

h { P' } S { $ Q' }, 
P =^> P', and 

To prove |= t { P } S { JJ. <5 } consider a state 5 such that P 5 = tt. Then P' s — 
tt and there is a state s' such that Q' s' — tt and 

{S, S) -> 5' 

However, we also have that <5 s' = tt and this proves the result. □ 

Exercise 6.31 Show that the inference rule for repeat S until b suggested in 
Exercise 6.29 preserves validity. Argue that this means that the entire proof system 
consisting of the axioms and rules of Table 6.2 together with the rule of Exercise 
6.29 is sound. □ 

Exercise 6.32 * Prove that the inference system of Table 6.2 is complete, that is 
\=t{P}S{llQ} implies \- t {P}S{llQ} □ 

Exercise 6.33 * Prove that 

if h t { P } S { i}, Q } then h p { P } S { Q } 
Does the converse result hold? □ 
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Extensions of While 

We conclude by considering an extension of While with non-determinism and 
(parameterless) procedures. The syntax of the extended language is given by 

S ::— x := a | skip | S\ ; S2 | if b then Si else 5 2 
while b do S \ Si or S2 
begin proc p is Si, S2 end | call p 

Note that in begin proc p is Si, S2 end the body of p is Si and the remainder 
of the program is S2 ■ 

Non-determinism 

It is straightforward to handle non-determinism (in the sense of Section 2.4) in 
the axiomatic approach. The idea is that an assertion holds for Si or S2 if the 
similar assertion holds for Si as well as for S2 ■ The motivation for this is that 
when reasoning about the statement we have no way of influencing whether Si or 
S2 is chosen. For partial correctness we thus extend Table 6.1 with the rule 



When dealing with soundness and completeness of these rules one must be careful 
in using a semantics that models "non-deterministic choice" in the proper manner. 
We saw in Section 2.4 that this is the case for structural operational semantics but 
not for natural semantics. With respect to the structural operational semantics one 
can show that the above rules are sound and that the resulting inference systems 
are complete. If one insists on using the natural semantics the or-construct would 
model a kind of "angelic choice" and both rules would be sound. However, only 
the partial correctness inference system will be complete. 

Non-recursive procedures 

For the sake of simplicity we shall restrict our attention to statements with at 
most one procedure declaration. For non-recursive procedures the idea is that an 
assertion that holds for the body of the procedure also holds for the calls of the 
procedure. This motivates extending the partial correctness inference system of 
Table 6.1 with the rule 




{P}Si{Q},{P}S 2 {Q} 
{ P } Si or S 2 { Q } 



For total correctness we extend Table 6.2 with the rule 



[ort] 



{P}Si{tyQ},{P}S 2 {tyQ} 
{ P } Si or S 2 { 4 Q } 
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[callp] 



{ P } S { Q} 



where p is defined by proc p is S 



{ P } call p { Q } 



Similarly the inference system for total correctness in Table 6.2 can be extended 
with the rule 



In both cases the resulting inference system can be proved sound and complete. 
Recursive procedures 

The above rules turn out to be insufficient when procedures are allowed to be 
recursive: in order to prove an assertion for call p one has to prove the assertion 
for the body of the procedure and this implies that one has to prove an assertion 
about each occurrence of call p inside the body and so on. 

Consider first the case of partial correctness assertions. In order to prove some 
property { P } call p { Q } we shall prove the similar property for the body of 
the procedure but under the assumption that { P } call p { Q } holds for the 
recursive calls of p. Often this is expressed by a rule of the form 



The premise of the rule expresses that { P } S { Q } is provable under the 
assumption that { P } call p { Q } can be proved for the recursive calls present 
in S. The conclusion expresses that { P } call p { Q } holds for all calls of p. 

Example 6.34 Consider the following statement 

begin proc f ac is (if x = 1 then skip 

else (y := x*y; x := x— 1; call fac)); 
y := 1; call fac 

end 

We want to prove that the final value of y is the factorial of the initial value of x. 
We shall prove that 

{x>0An = y*x! } call fac { y = n } 

where x > A n = y * x! is an abbreviation for the predicate P defined by 



[call t ] 



{P}S{^Q} 



where p is defined by proc p is S 



{ P } call p { ^ Q } 



[call^ ec ] 



{ P } call p{Q}^ p {P}S{Q} 

{ P } call p { Q } 
where p is defined by proc p is S 



P s = (s x > and s n = s y * (s x)\) 
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We assume that 

hp{x>0An = y*x! } call f ac { y = n } (*) 
holds for the recursive calls of f ac. We shall then construct a proof of 
{x>0An = y*x! } 

if x = 1 then skip else (y := x*y; x := x— 1; call fac) (**) 

{y = n} 

and, using [call™ ] we obtain a proof of (*) for all occurrences of call fac. To 
prove (**) we first use the assumption (*) to get 

hp{x>0An = y*x! } call fac { y = n } 

Then we apply [ass p ] and [comp p ] twice and get 

hp { ((x > A n = y * x!)[xi->x-l])[yi->x*y] } 
y := x*y; x := x— 1; call fac 

{y = n} 

We have 

->(x=l) A (x > A n = y * x!) =>((x>0An = y* x!)[xi->x-l])[yi->x*y] 
so using [consp] we get 

hp { ->(x=l) A (x > A n = y * x!) } 
y := x*y; x := x— 1; call fac 

{y = n} 

Using that 

x=lAx>OAn=y*x! y = n 
it is easy to prove 

hp { x=l Ax>0An = y*x! } skip { y = n } 
so [if p ] can be applied and gives a proof of (**). □ 

Table 6.1 extended with the rule [call p ec ] can be proved to be sound. However, 
in order to get a completeness result the inference system has to be extended with 
additional rules. To illustrate why this is necessary consider the following version 
of the factorial program: 
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begin proc f ac is if x=l then y := 1 

else (x := x— 1; call fac; x := x+1; y := x*y); 

call fac 

end 

Assume that we want to prove that this program does not change the value of x, 
that is 

{ x = n } call fac { x = n } (*) 

In order to do that we assume that we have a proof of (*) for the recursive call of 
fac and we have to construct a proof of the property for the body of the procedure. 
It seems that in order to do so we must construct a proof of 

{ x = n— 1 } call fac { x = n— 1 } 

and there are no axioms and rules that allow us to obtain such a proof from (*). 
However, we shall not go further into this, but Chapter 7 will provide appropriate 
references. 

The case of total correctness is slightly more complicated because we have to 
bound the number of recursive calls. The rule adopted is 

{ P(z) } call p { jj. Q } h { P(z+1) } S { Jj Q } 

{ 3z.P(z) } call p { Jj. Q } 
where ~>P(0) holds 

and z ranges over the natural numbers (that is z>0) 
and where p is defined by proc p is S 

The premise of this rule expresses that if we assume that we have a proof of 
{ P(z) } call p { JJ- Q } for all recursive calls of p of depth at most z then we 
can prove { P(z+1) } S { JJ- Q }. The conclusion expresses that for any depth of 
recursive calls we have a proof of { 3z.P(z) } call p { JJ- Q }. 

The inference system of Table 6.2 extended with the rule [call£ ec ] can be proved 
to be sound. If it is extended with additional rules (as discussed above) it can also 
be proved to be complete. 



6.5 Assertions for execution time 

A proof system for total correctness can be used to prove that a program does 
indeed terminate but it does not say how many resources it needs in order to 
terminate. We shall now show how to extend the total correctness proof system of 
Table 6.2 to prove the order of magnitude of the execution time of a statement. 
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It is easy to give some informal guidelines for how to determine the order of 
magnitude of execution time: 

assignment: the execution time is 0(1), that is, it is bounded by a constant, 
skip: the execution time is 0(1), 

composition: the execution time is, to within a constant factor, the sum of the 
execution times of each of the statements, 

conditional: the execution time is, to within a constant factor, the largest of the 
execution times of the two branches, and 

iteration: the execution time of the loop is, to within a constant factor, the sum, 
over all iterations round the loop, of the time to execute the body. 

The idea now is to formalize these rules by giving an inference system for reasoning 
about execution times. To do so we shall proceed in three stages: 

• first we specify the exact time needed to evaluate arithmetic and boolean 
expressions, 

• next we extend the natural semantics of Chapter 2 to count the exact exe- 
cution time, and 

• finally we extend the total correctness proof system to prove the order of 
magnitude of the execution time of statements. 

However, before addressing these issues we have to fix a computational model, that 
is we have to determine how to count the cost of the various operations. The 
actual choice is not so important but for the sake of simplicity we have based it 
upon the abstract machine of Chapter 3. The idea is that each instruction of 
the machine takes one time unit and the time required to execute an arithmetic 
expression, a boolean expression or a statement will be the time required to execute 
the generated code. However, no knowledge of Chapter 3 is required in the sequel. 

Exact execution times for expressions 

The time needed to evaluate an arithmetic expression is given by a function 
TA: Aexp -> Z 

so T*4|a] is the number of time units required to evaluate a in any state. Similarly, 
the function 

TB: Bexp ->■ Z 

determines the number of time units required to evaluate a boolean expression. 
These functions are defined in Table 6.3. 
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T~ A T^iT 

/ A\n\ 


— i 
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T A\a x + o 2 ] 


= T^IoJ + TA\a 2 \ + 1 

LL _U LL ^ _ll 


T A[a! * a 2 j 


= r^[ai] + T.4[a 2 ] + 1 


T A{a x - a 2 j 


= T^[ai] + T.A[a 2 ] + 1 

IL Jl IL ^ Jl 


/ o [true J 


= 1 


/ £>||IalseJ 


-1 

= 1 


/ £>|[Oi — a 2 J 


— T Mr, H -1- T Mr, 1 J. 1 

— / «A|aij -+- i J\\a 2 \ -+- l 


TB{a 1 < o 2 ] 


= TAM + TA{a 2 \ + 1 


TB[-.6] 


= TB[b] + l 


TB[6i A 6 2 ] 


= TB[6i] + T£[5 2 ] + 1 



Table 6.3: Exact execution times for expressions 



Exact execution times for statements 

Turning to the execution time for statements we shall extend the natural semantics 
of Table 2.1 to specify the time requirements. This is done by extending the 
transitions to have the form 

{S, s) ->* s' 

meaning that if S is executed from state s then it will terminate in state s' and 
exactly t time units will be required for this. The extension of Table 2.1 is fairly 
straightforward and is given in Table 6.4. 

The inference system 

The inference system for proving the order of magnitude of the execution time of 
statements will have assertions of the form 

{P}S{eilQ} 

where P and Q are predicates as in the previous inference systems and e is an 
arithmetic expression (that is e 6 Aexp). The idea is that 

if the execution of S is started in a state satisfying P 

then it terminates in a state satisfying Q 

and the required execution time is 0(e), that is has order of magnitude e. 
So for example 
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[ass tns ] (x:=a,s) -V™M+i s [xt-^A[d\s] 

[skip tns ] (skip, s) s 

<5i,a> s', (S 2 ,s') ^ s" 



[comp tns ] 



(Si]S 2 , s) ^* 1+ * 2 s" 



(S 2 ,s) s' 
(if b then Si else 5 2 , s) -*. TB L 6 J+* +1 s ' 

(S,s) -> f s', (while b do 5, 5') V s" 
[while£ s ] (while 6 do 5, 5) -^ B M+ 3 5 if B[6]a = ff 



Table 6.4: Natural semantics for While with exact execution times 

{ x = 3 } y := 1; while -i(x=l) do (y := y*x; x := x— 1) { 1 JJ- true } 

expresses that the execution of the factorial statement from a state where x has the 
value 3 has order of magnitude 1, that is it is bounded by a constant. Similarly, 

{ x > } y := 1; while -i(x=l) do (y := y*x; x := x— 1) { x JJ- true } 

expresses that the execution of the factorial statement on a state where x is positive 
has order of magnitude x. 

Formally, validity of the formula {P}S{ei}.Q} is defined by 

he { P } S { e JJ. Q } 
if and only if 

there exists a natural number k such that for all states s, 

if P s — tt then there exists a state s' and a number t such that 

Q s ' = tt, (S, s) ->•* a', and t < k ★ (A[e]s) 

Note that the expression e is evaluated in the initial state rather than the final 
state. 

The axioms and rules of the inference system are given in Table 6.5. Provability 
of the assertion {P}S{ei}.Q}m the inference system is written 

h e { P } S { e JJ. Q } 
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[ass e ] { P[x^4[a]] }x:=a{ll),P} 

[Skip e ] { P } Skip { 1 JJ. P } 

i {PA B[e' 2 =u] } S 1 { ei JJ. Q A £[e 2 <u] }, { Q } S 2 { e 2 JJ R } 



{ A P } Si { e JJ. g }, { -ng[6] A P } S 2 { e JJ. Q } 

{ P } if b then Si else S 2 { e JJ- Q } 

{ P(z+1) A B[e' =u] } S { ei JJ- P(z) A ^[e<u] } 

{ 3z.P(z) } while 6 do S { e JJ- P(0) } 
where P(z+1) B[bj A S[e>ei + e'], P(0) ^ A B[l<e] 



and Q' ^ Q 

Table 6.5: Axiomatic system for order of magnitude of execution time 

The assignment statement and the skip statement can be executed in constant 
time and therefore we use the arithmetic expression 1. 

The rule [comp e ] assumes that we have proofs showing that e\ and e 2 are the 
order of magnitudes of the execution times for the two statements. However, e\ 
expresses the time requirements of Si relative to the initial state of Si and e 2 
expresses the time requirements relative to the initial state of S 2 . This means that 
we cannot simply use e\ + e 2 as the time requirement for Si; S 2 . We have to 
replace e 2 with an expression e' 2 such that e' 2 evaluated in the initial state of Si 
will bound the value of e 2 in the initial state of S 2 (which is the final state of Si). 
This is expressed by the extended precondition and postcondition of Si using the 
logical variable u. 

The rule [if e ] is fairly straightforward since the time required for the test is 
constant. 

In the rule for the while-construct we assume that the execution time is e\ for 
the body and is e for the loop itself. As in the rule [comp e ] we cannot just use 
ei + e as the total time required because e\ refers to the state before the body 
of the loop is executed and e to the state after the body is executed once. We 



[comp e ] 



{ P } Si; S 2 { ei+e' 2 JJ- R } 
where u is an unused logical variable 



[cons e ] 
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shall therefore require that there is an expression e' such that e' evaluated before 
the body will bound e evaluated after the body. Then it must be the case that e 
satisfies e > e\ + e' because e has to bound the time for executing the while-loop 
independently of the number of times it is unfolded. As we shall see in Example 
6.36, this corresponds to the recurrence equations that often have to be solved 
when analysing the execution time of programs. Finally, the rule [cons e ] should be 
straightforward. 

Example 6.35 We shall now prove that the execution time of the factorial state- 
ment has order of magnitude x. This can be expressed by the following assertion: 

{ x > } y := 1; while -i(x=l) do (y := y*x; x := x— 1) { x JJ- true } 

The inference of this assertion proceeds in a number of stages. First we define the 
predicate INV(z) that is to be the invariant of the while-loop 

INV(z) s = (u>0 and s x = z + 1) 

The logical variables U! and u 2 are used for the while-loop and the body of the 
while-loop, respectively. We shall first consider the body of the loop. Using [ass e ] 
we get 

h e { (INV(z) A x<ui)[xi->x-l] } x := x - 1 { 1 ^ INV(z) A x<u x } 

Similarly, we get 

h e { ((INV(z) A x<ui)[xi-»x-l] A l<u 2 )[y^y*x] } 
y := y * x 

{ 1 JJ- (INV(z) A x<ui)[»-»x-l] A l<u 2 } 

Before applying the rule [comp e ] we have to modify the precondition of the above 
assertion. We have 

INV (z+1) A x-l=U! A l=u 2 

=> ((INV(z) A x<ui)[»-»x-l] A l<u 2 )[yi->y*x] 

so using [cons e ] we get 

h e { INV (z+1) A x-l= Ul A l=u 2 } 
y := y * x 

{ 1 ^ (INV(z) A x<ui)[»-»x-l] A l<u 2 } 
We can now apply [comp e ] and get 
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he { INV(Z+1) A X-l= Ul } 

y := y * x; x := x-1 
{ 1+1 ^ INV(z) A x< Ul } 
and using [cons e ] we get 

h e { INV (Z + 1) A X-l= Ul } 

y := y * x; x := x-1 
{ 1 ^ INV(z) A x< Ul } 

It is easy to verify that 

INV (z+1) => -.(x = 1) A x>l+(x-l), and 

/W(0) => -.(-.(x = 1)) A l<x 
Therefore we can use the rule [while e ] and get 

h e { 3z.INV(z) } while ->(x=l) do (y := y*x; x := x-1) { x ^ JJVy(O) } 
We shall now apply the axiom [ass e ] to the statement y := 1 and get 

h e { (3z.INV(z) A l<u 3 )[y^l] } y := 1 { 1 ^ 3z.INV(z) A l<u 3 } 
We have 

x>0 A l=u 3 => (3z.INV{z) A Ku 3 )[y^l] 
so using [cons e ] we get 

h e { x>0 A l=u 3 } y := 1 { 1 ^ 3z.INV{z) A l<u 3 } 
The rule [comp e ] now gives 

h e { x>0 } 

y := 1; while -i(x=l) do (y := y*x; x := x— 1) 
{ 1+x ^ INV(0) } 
Clearly we have 

x>0 => 1+x < 2*x, and 
INV(0) => true 
so applying rule [cons e ] we get 

h e { X > } 

y := 1; while -i(x=l) do (y :— y*x; x := x— 1) 
{ x JJ- true } 



6.5 Assertions for execution time 
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as required. □ 

Example 6.36 Assume now that we want to determine an arithmetic expression 
ef ac such that 

K { x > } 

y := 1; while -i(x=l) do (y := y*x; x := x— 1) 
{ e fac JJ- true } 

In other words we want to determine the order of magnitude of the time required 
to execute the factorial statement. We can then attempt constructing a proof 
of the above assertion using the inference system of Table 6.5 with ef ac being an 
unspecified arithmetic expression. The various side conditions of the rules will 
then specify a set of (in)equations that have to be fulfilled by ef ac in order for the 
proof to exist. 

We shall first consider the body of the loop. Very much as in the previous 
example we get 

h e { INV (z+1) A e[»-»x-l]=ui } 
y := y ★ x; x := x-1 
{ 1 ^ INV(z) A e< Ul } 

where e is the execution time of the while-construct. We can now apply the rule 
[while e ] if e fulfils the conditions 

INV (z+1) => e>l+e[x^x-l] 

INV(0) > Kc 

and we will get 

h e { 3z.INV(z) } while ->(x=l) do (y := y*x; x := x-l) { e INV(0) } 
The requirement (*) corresponds to the recurrence equation 

T(x) = 1 + T(x-l) 
T(l) = 1 

obtained by the standard techniques from execution time analysis. If we take e to 
be x then (*) is fulfilled. The remainder of the proof is very much as in Exercise 
6.35 and we get that ef ac must satisfy 

x > x+1 < k*ef ac for some constant k 



so ef ac may be taken to be x. 



□ 
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Exercise 6.37 Modify the proof of Lemma 6.30 to show that the inference system 
of Table 6.5 is sound. □ 

Exercise 6.38 ** Suggest an alternative rule for while b do S that expresses 
that its execution time, neglecting constant factors, is the product of the number 
of times the loop is executed and the maximal execution time for the body of the 
loop. □ 

Exercise 6.39 Suggest an inference rule for repeat S until b. You are not 
allowed to rely on the existence of a while-construct in the language. □ 



Chapter 7 
Further Reading 



In this book we have covered the basic ingredients in three approaches to semantics: 

• operational semantics, 

• denotational semantics, and 

• axiomatic semantics. 

We have concentrated on a rather simple language of while-programs and have 
studied the underlying theories and the formal relationships between the various 
approaches. The power of the three approaches have been illustrated by vari- 
ous extensions of While: non-determinism, parallelism, recursive procedures and 
exceptions. 

We believe that formal semantics is an important tool for reasoning about many 
aspects of the behaviour of programs and programming languages. To support this 
belief we have given three examples, one for each approach to semantics: 

• a simple compiler, 

• a static program analysis, and 

• an inference system for execution time. 

In conclusion we shall provide a few pointers to the literature (mainly textbooks) 
where a more comprehensive treatment of language features or theoretical aspects 
may be found. We do not reference the vast number of research publications in 
the area but rely on the references in the books mentioned. 

Operational semantics 

Structural operational semantics was introduced by Gordon Plotkin in [14]. This 
is a standard reference and covers a number of features from imperative and func- 
tional languages whereas features from parallel languages are covered in [15]. A 
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more introductory treatment of structural operational semantics is given in [9]. 
Natural semantics is derived from structural operational semantics and the basic 
ideas are presented in [6] for a functional language. 

Although we have covered many of the essential ideas behind operational se- 
mantics we should like to mention three techniques that have had to be omitted. 

A technique that is often used when specifying a structural operational se- 
mantics is to extend the syntactic component of the configurations with special 
notation for recording partially processed constructs. The inference system will 
then contain axioms and rules that handle these "extended" configurations. This 
technique may be used to specify a structural operational semantics of the lan- 
guages Block and Proc in Section 2.5 and to specify a structural operational 
semantics of expressions. 

Both kinds of operational semantics can easily be extended to cope explicitly 
with dynamic errors (as e.g. division by zero). The idea is to extend the set of 
configurations with special error-configurations and then augment the inference 
system with extra axioms and rules for how to handle these configurations. 

Often programs have to fulfil certain conditions in order to be statically well- 
formed and hence preclude certain dynamic errors. These conditions can be 
formulated using inductively defined predicates and may be integrated with the 
operational semantics. 

Provably correct implementation 

The correctness of the implementation of Chapter 3 was a relatively simple proof 
because it was based on an abstract machine designed for the purpose. In general, 
when more realistic machines or larger languages are considered, proofs easily 
become unwieldy and perhaps for this reason there is no ideal textbook in this 
area. We therefore only reference two research papers: [7] for an approach based 
on natural semantics and [13] for an approach based on denotational semantics. 

Denotational semantics 

A general introduction to denotational semantics (as developed by C. Strachey 
and D. Scott) may be found in [16]. It covers denotational semantics for (mainly) 
imperative languages and covers the fundamentals of domain theory (including 
reflexive domains). Another good reference for imperative languages is [8] but it 
does not cover the domain theory. We should also mention a classic in the field 
[17] even though the domain theory is based on the (by now obsolete) approach of 
complete lattices. 

We have restricted the treatment of domain theory to what is needed for speci- 
fying the denotational semantics of the while-language. The benefit of this is that 
we can restrict ourselves to partial functions between states and thereby obtain a 
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relatively simple theoretical development. The drawback is that it becomes rather 
cumbersome to verify the existence of semantic specifications for other languages 
(as evidenced in Section 4.5). 

The traditional solution is to develop a meta-language for expressing denota- 
tional definitions. The theoretical foundation of this language will then ensure that 
the semantic functions do exist as long as one only uses domains and operations 
from the meta-language. The benefit of this is obvious; the drawback is that one 
has to prove a fair amount of results but the efforts are greatly rewarded in the 
long run. Both [16] and [17] contain such a development. 

The denotational approach can handle abortion and non- determinism using 
a kind of powersets called power-domains. Certain kinds of parallelism can be 
handled as well but for many purposes it is better to use a structural operational 
semantics instead. 

Static program analysis 

A selection of static program analysis techniques for imperative languages (as well 
as techniques for implementations on realistic machines) is given in [3]; but unfor- 
tunately, no considerations of correctness are given. Treatments of correctness are 
often based on abstract interpretation and [1] surveys a number of approaches. 

Axiomatic program verification 

A general introduction to program verification, and in particular axiomatic se- 
mantics may be found in [11]. The presentation covers a flowchart language, a 
while- language and a (first order) functional language and also includes a study 
of expressiveness (as needed for the intensional approach to axiomatic semantics). 
Many books, including [10], develop axiomatic program verification together with 
practically motivated examples. A good introduction to the analysis of resource 
requirements of programs is [2] and the formulation as formal inference systems 
may be found in [12]. We should also mention a classic [5] that studies soundness 
and completeness properties with respect to a denotational semantics. Rules for 
procedures may be found in [4]. 

We should point out that we have used the extensional approach to specifying 
the assertions of the inference systems. This allows us to concentrate on the 
formulation of the inference systems without having to worry about the existence 
of the assertions in an explicit assertion language. However, it is more common to 
use the intensional approach as is done in [11]. 
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Appendix A 
Review of Notation 



We use the following notation: 



3 


there exists 


V 

V 


TOT* 5} 1 1 

1U1 dll 


{ X . X . 1" 


tVip spt of tliosp t sncli tViat t linlHs 




7 1 ic q TTlPlTlllPT OT flip ^pt 

ID d UlClllL'Cl \J± IjIIC OCt -/I. 


X C Y 


cpt V ic pnTit^iTipn in cpt 
Oct YY ID CUllldlllct-l 111 act I 


A U J 


{ z z£A or z£ Y \ (union) 


x n F 


{ z z(EX and z(E Y } (intersection) 


X \ F 


{ z zeX and z^Y } (set difference) 


X x F 


{ (z, y) x6;X and y(E Y } (Cartesian product) 


7>(X) 


{ Z \ Z C X } (powerset) 




{ 2/ | 3Yey: yeY } (so that U{ Y u F 2 } = F X UF 2 ) 





the empty set 


T 


{ tt, ff } (truth values tt (true) and ff (false)) 


N 


{ 0, 1, 2, ... } (natural numbers) 


Z 


{ ...,-2, 1, 0, 1, 2, ... } (integers) 


/:X^F 


/ is a total function from X to F 


X^F 


{/ |/:X^F} 


/:X^F 


/ is a partial function from X to F 


X-^F 


{ / |/:X^F} 


In addition to this we 


have special notations for functions, relations, predicates 
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and transition systems. 
Functions 

The effect of a function f:X^Y is expressed by its graph: 

graph(/) = { (x, y)EXxY \fx = y} 
which is merely an element of V (X x Y) . The graph of / has the following properties 

• {x, y)egraph(/) and {x, ?/')egraph(/) imply y — y', and 

• Mx^X: 3yEY: (x, y)E graph(/) 

This expresses the single- valuedness of / and the totality of /. We say that / is 
injective if / x = f x' implies that x — x'. 

A partial function g:X^Y is a function from a subset X g of X to Y, that is 
g:X g ^>- Y. Again one may define 

graph(#) = { (x, y)eXx Y \ g x = y and xeX g } 

but now only an analogue of the single-valuedness property above is satisfied. We 
shall write g x — y whenever (x, y)Egraph(g) and g x = undef whenever x^X gi 
that is whenever ->3yEY: (x, y)egraph(^). To distinguish between a function / 
and a partial function g one often calls / a total function. We shall view the partial 
functions as encompassing the total functions. 

For total functions /i and / 2 we define their composition /20/1 by 



(Note that the opposite order is sometimes used in the literature.) For partial 
functions gi and g 2 we define <72°<?i similarly: 



(92°9i) x — undef if gi x = undef or 

if there exists y such that g\ x — y 
but g 2 y = undef 
The identity function id:X— >X is defined by 
id x = x 

Finally, if f:X—*Y, xEX and y£ Y then the function f[xt->y]:X—>Y is defined by 



A similar notation may be used when / is a partial function. 

The function / is of order of magnitude g, written O(g), if there exists a natural 
number k such that Vx. / x < k * [g x). 



(/20/1) x = / 2 (/i x) 



if there exists y such that g\ x — y and g 2 y — z 
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Relations 

A relation from X to Y is a subset oflxF (that is an element of V(X x Y)). A 
relation on X is a subset of X xX . If f:X—> Y or Y then the graph of / is a 

relation. (Sometimes a function is identified with its graph but we shall keep the 
distinction.) The identity relation on X is the relation 

I x = { (x, x) I xeX } 

from X to X. When X is clear from the context we shall omit the subscript X 
and simply write I. 

If iZxCXx Y and R 2 CYxZ the composition of Ri followed by R 2 , which we 
denote by Ri<>R 2 , is defined by 

R 1 oR 2 = { (x, z) | 3yeY: (x, y)eRi and (y, z)eR 2 } 
Note that the order of composition differs from that used for functions, 

graph^ao/i) = graph (/i) o graph(/ 2 ) 
and that we have the equation 

I o R = R o I = R 

If R is a relation on X then the reflexive transitive closure is the relation R* 
on X defined by 

R* — { (x, x') | 3n>l: 3xi, . . ., x n : x — X\ and x' = x n 
and Vi<n: (x- u x- l+ i)^R } 

Note that by taking n=l and x—x'—Xi it follows that ICR*. In a similar way it 
follows that RCR*. Finally, we define 

R + = R o R* 

and observe that R C R + C R*. 

Predicates 

A predicate on X is a function from X to T. If p:X— >T is a predicate on X , the 
relation I p on X is defined by 

l p — { {x, x) | j£l and p x — tt } 

Note that I p C I and that 

l p o R — { {x, y) | p x = tt and (x, } 
i? o I 9 = { (i, i/) | (z, and q y = tt } 
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Transition systems 

A transition system is a triple of the form 

(ryr, >) 

where T is a set of configurations, T is a subset of Y called the terminal (or final) 
configurations and > is a relation on Y called a transition relation. The relation 
> must satisfy 

V7eT: vyer: ->(7>V) 

Any configuration 7 in Y\T such that the transition 7>7' holds for no 7' is called 
stuck. 



Appendix B 

Introduction to Miranda 
Implementations 

In this appendix we give the basic definitions needed to implement the various 
semantic definitions in Miranda. Essentially, this amounts to an implementation 
of the material of Chapter 1. 

B.l Abstract syntax 

For Num we choose the primitive type num of Miranda. For Var we choose 
strings of characters and so define the type synonym: 

> var == [char] 

For each of the syntactic categories Aexp, Bexp and Stm we define an algebraic 
data type taking into account the various possibilities mentioned by the BNF 
syntax of Section 1.2: 

> aexp : := N num I V var I Add aexp aexp I 

> Mult aexp aexp I Sub aexp aexp 

> bexp : := TRUE I FALSE I Eq aexp aexp I Le aexp aexp I 

> Neg bexp I And bexp bexp 

> stm : := Ass var aexp I Skip I Comp stm stm I 

> If bexp stm stm I While bexp stm 

Example B.l The factorial statement of Exercise 1.1 is represented by 
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> factorial = Comp (Ass "y" (N 1)) 

> (While (Neg (Eq (V "x") (N 1))) 

> (Comp (Ass "y" (Mult (V "y") (V "x"))) 

> (Ass "x" (Sub (V "x") (N 1))))) 

Note that this is a representation of the abstract syntax of the statement. One 
may be interested in a parser that would translate the more readable form 

y := 1; while -i(x = 1) do (y := y * x; x : = x — 1) 

into the above representation. However, we shall refrain from undertaking the task 
of implementing a parser as we are mainly concerned with semantics. □ 

Exercise B.2 Specify an element of stm that represents the statement constructed 
in Exercise 1.2 for computing n to the power of m. □ 



B.2 Evaluation of expressions 

We shall first be concerned with the representation of values and states. The 
natural numbers Z will be represented by the type num meaning that the semantic 
function J\f becomes trivial. The truth values T will be represented by the type 
bool of booleans. So we define the type synonyms: 

> z == num 

> t == bool 

The set State is defined as the set of functions from variables to natural numbers 
so we define: 

> state == var -> z 

Example B.3 The state s_init that maps all variables except x to and that 
maps x to 3 can be defined by 

> s_init "x" = 3 

> s_init y =0 

Note that we encapsulate the specific variable name x in quotes whereas y can be 
any variable. □ 

The functions A and B will be called a_val and b_val in the implementation 
and they are defined by directly translating Tables 1.1 and 1.2 into Miranda: 
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> a_val : : aexp -> state -> z 

> b_val : : bexp -> state -> t 

> a_val (N n) s = n 

> a_val (V x) s = s x 

> a_val (Add al a2) s = (a_val al s) + (a_val a2 s) 

> a_val (Mult al a2) s = (a_val al s) * (a_val a2 s) 

> a_val (Sub al a2) s = (a_val al s) - (a_val a2 s) 

> b_val TRUE s = True 

> b_val FALSE s = False 

> b_val (Eq al a2) s = True, if a_val al s = a_val a2 s 

> = False, if_ a_val al s ~= a_val a2 s 

> b_val (Le al a2) s = True, if a_val al s <= a_val a2 s 

> = False, if_ a_val al s > a_val a2 s 

> b_val (Neg b) s = True, if b_val b s = False 

> = False, if_ b_val b s = True 

> b_val (And bl b2) s = True, if b_val bl s = True & 

> b_val b2 s = True 

> = False, if_ b_val bl s = False \/ 

> b_val b2 s = False 

Exercise B.4 Construct an algebraic data type for the binary numerals consid- 
ered in Section 1.3. Define a function n_val that associates a number (in the 
decimal system) to each numeral. □ 

Exercise B.5 Define functions 

> f v_aexp : : aexp -> [var] 

> f v_bexp : : bexp -> [var] 

computing the set of free variables occurring in an expression. Ensure that each 
variable occurs at most once in the resulting lists. □ 

Exercise B.6 Define functions 

> subst_aexp : : aexp -> var -> aexp -> aexp 

> subst_bexp : : bexp -> var -> aexp -> bexp 
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implementing the substitution operations, that is subst_aexp a y a constructs 
a[y\- >a ] and subst_bexp b y a constructs b[y\- >a ]. □ 



Appendix C 

Operational Semantics in 
Miranda 

In this appendix we implement the natural semantics and the structural opera- 
tional semantics of Chapter 2 in Miranda and show how similar techniques can be 
used to implement an interpreter for the abstract machine and the code generation 
of Chapter 3. 

We shall need the definitions from Appendix B so we begin by including these: 

> °/,include "appB" 

In Chapter 2 we distinguish between two kinds of configurations, intermediate 
configurations and final configurations. This is captured by the algebraic data 
type: 

> config ::= Inter stm state I Final state 

In the next section we shall show how the natural semantics can be implemented 
and after that we shall turn to the structural operational semantics. 

C.l Natural semantics 

Corresponding to the relation — > in Section 2.1 we shall introduce a function ns_stm 
of type 

> ns_stm : : config -> config 

The argument of this function corresponds to the left-hand side of — > whereas 
the result produced will correspond to the right-hand side of the relation. This 
is possible because Theorem 2.9 shows that the relation is deterministic. The 
definition of ns_stm follows closely the definition of — > in Table 2.1: 
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> ns_stm (Inter (Ass x a) s) 

> = Final (update s x (a_val as)) 

> where 

> update sxvy=v, if x = y 

> = s y, otherwise 

> ns_stm (Inter (Skip) s) = Final s 

> ns_stm (Inter (Comp ssl ss2) s) 

> = Final s ' ' 

> where 

> Final s' = ns_stm (Inter ssl s) 

> Final s'' = ns_stm (Inter ss2 s') 

> ns_stm (Inter (If b ssl ss2) s) 

> = Final s ' , if_ b_val b s 

> where 

> Final s' = ns_stm (Inter ssl s) 

> ns_stm (Inter (If b ssl ss2) s) 

> = Final s ' , if ~b_val b s 

> where 

> Final s' = ns_stm (Inter ss2 s) 

> ns_stm (Inter (While b ss) s) 

> = Final s ' ' , if b_val b s 

> where 

> Final s' = ns_stm (Inter ss s) 

> Final s'' = ns_stm (Inter (While b ss) s J ) 

> ns_stm (Inter (While b ss) s) 

> = Final s , if ~b_val b s 



Note that in the axiom for assignment update s x v corresponds to s[a;i— 
The semantic function S ns can now be defined by 



C.2 Structural operational semantics 
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> s_ns ss s = s' 



> 



where 



> 



Final s' = ns_stm (Inter ss s) 



Example C.l We can execute the factorial statement (see Example B.l) from 
the state s_init mapping x to 3 and all other variables to (see Example B.3). 
The final state s_f ac is obtained as follows: 

> s_fac = s_ns factorial s_init 



Exercise C.2 Extend the definition of stm and ns_stm to include the repeat- 



Exercise C.3 Define an algebraic data type deriv_tree representing the deriva- 
tion trees of the natural semantics. Construct a variant of the function s_ns of 
type 

s_ns : : stm -> state -> deriv_tree 

that constructs the derivation tree for a given statement and state rather than just 
the final state. Apply the function to some example statements. □ 

C.2 Structural operational semantics 

When specifying the structural operational semantics we shall need to test whether 
produces an intermediate configuration or a final configuration. So we shall 
introduce the function is_Final defined by: 

> is_Final (Inter ss s) = False 

> is_Final (Final s) = True 

Corresponding to the relation =>- we define the function sos_stm of type: 

> sos_stm : : conf ig -> conf ig 

As in the previous section the argument of this function will correspond to the con- 
figuration on the left-hand side of the relation =>• and the result will correspond to 
the right-hand side. Again this implementation technique is only possible because 
the semantics is deterministic (Exercise 2.22). The definition of sos_stm follows 
Table 2.2 closely: 



To get the final value of y we evaluate s_fac "y". 



□ 



construct. 



□ 
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> sos_stm (Inter (Ass x a) s) 

> = Final (update s x (a_val as)) 

> where 

> update sxvy=v, if x = y 

> = s y, otherwise 

> sos_stm (Inter Skip s) = Final s 

> sos_stm (Inter (Comp ssl ss2) s) 

> = Inter (Comp ssl' ss2) s', 

> if ~is_Final(sos_stm (Inter ssl s)) 

> where 

> Inter ssl' s' = sos_stm (Inter ssl s) 

> sos_stm (Inter (Comp ssl ss2) s) 

> = Inter ss2 s ' , 

> if is_Final (sos_stm (Inter ssl s)) 

> where 

> Final s' = sos_stm (Inter ssl s) 

> sos_stm (Inter (If b ssl ss2) s) 

> = Inter ssl s, if b_val b s 

> sos_stm (Inter (If b ssl ss2) s) 

> = Inter ss2 s, if ~b_val b s 

> sos_stm (Inter (While b ss) s) 

> = Inter (If b (Comp ss (While b ss)) Skip) s 



The function sos_stm implements one step of the computation. The function 
deriv_seq defined below will determine the complete derivation sequence (even if 
it is infinite!). 

> deriv_seq (Inter ss s) 

> = (Inter ss s) : (deriv_seq (sos_stm (Inter ss s))) 

> deriv_seq (Final s) = [Final s] 

The semantic function S sos can now be defined by the Miranda function s_sos: 



C.3 Extensions of While 
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> s_sos ss s = s' 



> 



where 



> 



Final s' = last (deriv_seq (Inter ss s)) 



Example C.4 The derivation sequence obtained by executing the factorial state- 
ment on the state s_init of Example B.3 can now be obtained as follows: 

> fac_seq = deriv_seq (Inter factorial s_init) 

We may want to inspect this in more detail and in particular we may be interested 
in the values of the variables x and y in the various intermediate states. To 
facilitate this we use the function 

> show_seq fv 1 = lay (map show_config 1) 

> where 

> show_config (Final s) = 

> "final state : \n"++lay (map (show_val s) fv) 

> show_config (Inter ss s) = 

> show ss++"\n"++lay (map (show_val s) fv) 

> show_val s x = " s ("++x++")="++shownum (s x) 

The function call show_seq ["x" , "y"] f ac_seq will for each configuration in the 
derivation sequence f ac_seq list the statement part and the values of x and y in 
the state part. 

The final state of the derivation sequence can be obtained from 

> s_fac' = s_sos factorial s_init 

and the value obtained for y is obtained by executing s_fac J "y". □ 

Exercise C.5 Extend the definition of stm and sos_stm to include the repeat- 
construct. □ 



The implementation of the natural semantics of While in Section C.l will now be 
extended to the procedure language Proc of Section 2.5. Rather than presenting 
a fully worked out implementation we shall give detailed instructions for how to 
construct it. We shall pay special attention to the semantics of Proc with static 
scope rules for variables as well as procedures. 
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Exercise C.6 The first step will be to define the datatypes needed to represent 
the syntax and the semantics of Proc. 

• Extend the algebraic data type stm with the new forms of statements and 
define algebraic data types dec_V and dec_P for variable declarations and 
procedure declarations. 

• Define the algebraic type loc to be num such that locations will be numbers. 
Define the function 

new : : loc -> loc 

such that new increments its argument by one. 

• Define algebraic types env_V and env_P corresponding to Env v and Env P . 
Define the function 

upcLP : : (dec_P, env_V, env_P) -> env_P 

corresponding to updp. 

• Finally, we need a type store corresponding to Store. There are at least 
three possibilities: One possibility is to define 

loc' : := Loc loc | Next 
store == loc' -> z 

as this will correspond closely to the definition of Store. Alternatively, one 
may identify the special token 'next' with location and then simply define 

store == loc -> z 

The third possibility is to define 

store == (loc -> z, loc) 

where the second component corresponds to the value of 'next'. 

Choose a method that seems appropriate to you. □ 

Exercise C.7 Finally we turn towards the transition systems. We begin by im- 
plementing the transition system for variable declarations: 

• Define an algebraic data type conf ig_D for the configurations of the transi- 
tion system for variable declarations. 

• Then define a function 
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ns_dec_V : : conf ig_D -> conf ig_D 

corresponding to the relation — 
Now we turn to the transition relation for statements: 

• Define an algebraic data type conf ig_P corresponding to the configurations 
(S, sto) and sto of the transition system. 

• Next define a function 

ns_stm : : (env_V, env_P) -> conf ig_P -> conf ig_P 

corresponding to the transition relation — h 

Finally define a function 

s_ns : : stm -> store -> store 

that calls ns_stm with appropriately initialized environments. Use the function on 
various example statements in order to ensure that the implementation works as 
intended. □ 

Exercise C.8 Modify the implementation above to use dynamic scope rules for 
variable declarations as well as procedure declarations. □ 

It is more problematic to extend the implementation to handle the constructs 
of Section 2.4: 

Exercise C.9 Discuss how to extend the implementation of the natural semantics 
in Section C.l to incorporate the constructs considered in Section 2.4. □ 

Exercise C.10 Discuss how to extend the implementation of the structural oper- 
ational semantics of Section C.2 to incorporate the constructs considered in Section 
2.4. □ 



C.4 Provably correct implementation 

Rather than presenting a fully worked out Miranda script we shall provide exer- 
cises showing how to develop an implementation corresponding to Chapter 3. 

Exercise C.ll We need some data types to represent the configurations of the 
machine: 

• Define an algebraic data type am_ins for representing instructions and define 
the type synonym 
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am_code == [am_ins] 

for representing code. 

• Define an algebraic data type stack_values representing the elements that 
may be on the evaluation stack and define the type synonym 

stack == [stack_values] 

• Define a type storage representing the storage. 
Finally define 

am_config == (am_code, stack, storage) 
for the configurations of AM. □ 

Exercise C.12 We can then turn to the semantics of the machine instructions. 
For this we proceed in three stages: 

• First define a function am_step of type 

am_step : : am_conf ig -> am_conf ig 
implementing Table 3.1. 

• We shall also be interested in the computation sequences of AM so define a 
function 

am_comp_seq : : am_code -> storage -> [am_conf ig] 

that given a sequence of instructions and an initial storage will construct the 
corresponding computation sequence. 

• Finally define a function run corresponding to the function M. of Chapter 3. 

This provides us with an interpreter for AM. What happens if we enter a stuck 
configuration? □ 

Exercise C.13 Finally, we implement the code generation functions: 

• Define functions corresponding to CA, CB and CS. 

• Define a function am_stm corresponding to the function <S am . 

Apply the construction to a couple of examples to verify that everything works as 
expected. □ 

Exercise C.14 Modify the implementation to use the abstract machine AM 2 of 
Exercises 3.8 and 3.17 rather than AM. □ 



Appendix D 

Denotational Semantics in 
Miranda 

In this appendix we implement the denotational semantics of Chapter 4 in Mi- 
randa and show how similar techniques can be used to implement the static 
program analysis of Chapter 5. 

We shall need the definitions from Appendix B so we begin by including these: 

> °/,include "appB" 

D.l Direct style semantics 

In the implementation we shall rely on some of the built-in functions of Miranda. 
In particular, id is the identity function and '.' is function composition. The 
auxiliary function cond is defined by 

> cond (p, gl, g2) s = gl s, if p s 

> = g2 s, if "p s 

The theoretical foundation of Miranda is closely related to the theory developed 
in Chapter 4 (although it is outside the scope of this book to go further into 
this). One of the consequences of this is that the fixed point operation can be 
implemented in a very simple way: 

> fix ff = ff (fix ff) 

The function <S ds can now be implemented by the function 

> s_ds : : stm -> state -> state 

A straightforward rewriting of Table 4.1 gives: 
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> s_ds (Ass x a) s = update s (a_val a s) x 

> where 

> update svxy=v, if x = y 

> = s y, otherwise 

> s_ds Skip = id 

> s_ds (Comp ssl ss2) = (s_ds ss2) . (s_ds ssl) 

> s_ds (If b ssl ss2) = cond (b_val b, s_ds ssl, s_ds ss2) 

> s_ds (While b ss) = fix ff 

> where 

> ff g = cond (b_val b, g . s_ds ss, id) 

Example D.l Returning to the factorial statement we can apply its denotation 
to the initial state s_init as follows: 

> s_final = s_ds factorial s_init □ 

Exercise D.2 We may be interested in the various iterands of the fixed point. 
Rewrite the semantic equations above so that each fixed point is unfolded at most n 
times where n is an additional parameter to the functions. Give examples showing 
that if the value of n is sufficiently large then we get the same result as above. □ 

Exercise D.3 Extend the definition above to handle the repeat-construct. □ 



D.2 Extensions of While 

It is fairly straightforward to extend the implementation to handle the procedure 
language and the exception language of Section 4.5. 

Exercise D.4 Modify the above implementation to use environments and stores 
and extend it to implement the semantics of the language Proc of Section 4.5. □ 

Exercise D.5 Modify the above implementation to use continuations and extend 
it to handle the language Exc of Section 4.5. □ 



D.3 Static program analysis 

Rather than presenting a fully worked out Miranda script performing the depen- 
dency analysis we shall provide a rather detailed list of instructions for how to 
develop such an implementation. 



D.3 Static program analysis 
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Exercise D.6 The first step will be to implement the complete lattices P and 
PState and the operations on them: 

• Define an algebraic data type property representing the set P of properties 
and define a function p_lub corresponding to Up. 

• Define a type synonym pstate representing the property states. Define 
the special property states init and lost. Define a function pstate_lub 
corresponding to U PS . □ 

Exercise D.7 We can then turn to the semantic equations defining the analysis: 

• Define the functions 

p_aexp : : aexp -> pstate -> property 
corresponding to VA and 

p_bexp : : bexp -> pstate -> property 
corresponding to VB. 

• Define the auxiliary function cond_P corresponding to condp. 

• Define the function 

p_stm : : stm -> pstate -> pstate 

corresponding to VS of Table 5.2. (You may use the results of Section 5.4 
for this.) □ 

Exercise D.8 Implement the algorithm of Section 5.2 and apply the implemen- 
tation to a couple of examples to verify that everything works as expected. □ 
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